Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Possible memory corruption problem
05-09-2012, 04:13 PM
Post: #1
Possible memory corruption problem
A user has reported a crash in MinimWatch/ohNet. MinimWatch uses the ohNet control point stack only. The crash happened when Mountain Lion woke the user's Mac during a time that it was supposed to be in standby, presumably to do some system maintenance. The system log shows the network being disabled and enabled immediately before the crash (see red highlights):

Aug 31 04:14:48 iMacGK-2.local com.apple.backupd[5567]: Copied 4974 files (145,8 MB) from volume NewHD.
Aug 31 04:14:48 iMacGK-2.local com.apple.backupd[5567]: Using file event preflight for NewHD
Aug 31 04:14:48 iMacGK-2.local com.apple.backupd[5567]: Will copy (119,8 MB) from NewHD
Aug 31 04:14:48 iMacGK-2.local com.apple.backupd[5567]: Found 18 files (119,8 MB) needing backup
Aug 31 04:14:48 iMacGK-2.local com.apple.backupd[5567]: 3,15 GB required (including padding), 473,5 GB available
Aug 31 04:14:52 iMacGK-2 kernel[0]: enet_event_func - vendor 1, class 1, subclass 2, event code 12
Aug 31 06:02:05 iMacGK-2.local com.apple.backupd[5567]: Copied 93,5 MB of 119,8 MB, 33 of 33 items
Aug 31 06:02:05 iMacGK-2 kernel[0]: Wake reason: RTC (Alarm)
Aug 31 06:02:05 iMacGK-2 kernel[0]: RTC: Maintenance 2012/8/31 04:02:05, sleep 2012/8/31 02:14:53
Aug 31 06:02:05 iMacGK-2 kernel[0]: Previous Sleep Cause: 0
Aug 31 06:02:06 iMacGK-2.local hidd[44]: MultitouchHID: device bootloaded
Aug 31 06:02:07 iMacGK-2.local coreaudiod[152]: 2012-08-31 06:02:07.191427 AM [BonjourBrowser] ### <radar:6451163> Remove of non-existent Living Room Apple TV._airplay._tcp.local.%4
Aug 31 06:02:07 iMacGK-2.local coreaudiod[152]: 2012-08-31 06:02:07.191655 AM [BonjourBrowser] ### <radar:6451163> Remove of non-existent 5855CA0A1CF0@Living Room Apple TV._raop._tcp.local.%4
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyPreampTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyProductTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyRadioTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyPlaylistTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyDsTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyInfoTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyReceiverTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifySdpTimeout
Aug 31 06:02:08 iMacGK-2.local ChorusDS[4461]: notifyTimeTimeout
Aug 31 06:02:08 iMacGK-2 kernel[0]: enet_event_func - vendor 1, class 1, subclass 2, event code 13
Aug 31 06:02:08 iMacGK-2 kernel[0]: Ethernet [AppleYukon2]: Link up on en0, 1-Gigabit, Full-duplex, Symmetric flow-control, Debug [796d,af08,0de1,0200,cde1,2800]
Aug 31 06:02:11 iMacGK-2 kernel[0]: Graphics suppressed 6430 ms
Aug 31 06:02:11 iMacGK-2.local configd[18]: network changed: v4(en0-:10.0.1.31) DNS- Proxy- SMB
Aug 31 06:02:11 iMacGK-2.local awacsd[54]: InnerStore GetWakeInfoForZone: zero address for 176210256.members.btmm.icloud.com.
Aug 31 06:02:11 --- last message repeated 2 times ---
Aug 31 06:02:11 iMacGK-2.local awacsd[54]: KV HTTP 0
Aug 31 06:02:11 iMacGK-2.local configd[18]: network changed: v4(en0+:10.0.1.31) DNS+ Proxy+ SMB
Aug 31 06:02:11 iMacGK-2.local awacsd[54]: InnerStore GetWakeInfoForZone: zero address for 176210256.members.btmm.icloud.com.
Aug 31 06:02:15 iMacGK-2 com.apple.launchd.peruser.501[184] ([0x0-0x1b01b].com.minimserver.watch[263]): Job appears to have crashed: Segmentation fault: 11
Aug 31 06:02:17 iMacGK-2.local ReportCrash[5656]: Saved crash report for JavaApplicationStub[263] version 0.52 (???) to /Users/guuskeder/Library/Logs/DiagnosticReports/JavaApplicationStub_2012-08-31-060217_iMacGK-2.crash

Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyPreampTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyProductTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyRadioTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyPlaylistTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyDsTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyInfoTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifyReceiverTimeout
Aug 31 06:02:18 iMacGK-2.local ChorusDS[4461]: notifySdpTimeout

I'm attaching the crash report for the MinimServer process. This shows a segmentation fault in a memory allocation call. Errors like this are normally caused by native code writing into an incorrect memory area (possibly memory that has previously been freed).

Does this look similar to any other problems you have seen?


Attached File(s)
.txt  minimwatch-crash.txt (Size: 103.98 KB / Downloads: 2)
Find all posts by this user
05-09-2012, 04:21 PM (This post was last modified: 05-09-2012 04:22 PM by simonc.)
Post: #2
RE: Possible memory corruption problem
(05-09-2012 04:13 PM)simoncn Wrote:  A user has reported a crash in MinimWatch/ohNet. MinimWatch uses the ohNet control point stack only. The crash happened when Mountain Lion woke the user's Mac during a time that it was supposed to be in standby, presumably to do some system maintenance. The system log shows the network being disabled and enabled immediately before the crash:

[snip]

I'm attaching the crash report for the MinimServer process. This shows a segmentation fault in a memory allocation call. Errors like this are normally caused by native code writing into an incorrect memory area (possibly memory that has previously been freed).

Does this look similar to any other problems you have seen?

We haven't had any similar reports previously. There have been quite a few deadlocks and crashes inside subnet change handlers but none have involved writing to other people's memory. All have failed with a call stack which included the problem ohNet code.

Are you using the latest ohNet? If not, it'd be worth updating that first before trying any more involved debugging.
Find all posts by this user
05-09-2012, 07:48 PM
Post: #3
RE: Possible memory corruption problem
(05-09-2012 04:21 PM)simonc Wrote:  We haven't had any similar reports previously. There have been quite a few deadlocks and crashes inside subnet change handlers but none have involved writing to other people's memory. All have failed with a call stack which included the problem ohNet code.

Are you using the latest ohNet? If not, it'd be worth updating that first before trying any more involved debugging.

I don't have any particular reason to think that ohNet was to blame, but I thought it was worth asking the question. As you say, ohNet doesn't show up in the stack trace of the thread that crashed.

The ohNet library in the current release of MinimWatch was built on 29th April. I'll send the user a test build with the current level of ohNet. If the problem happens again, I'll let you know.
Find all posts by this user


Forum Jump: