debugging EXC_BAD_ACCESS
debugging EXC_BAD_ACCESS
- Subject: debugging EXC_BAD_ACCESS
- From: James Whitwell <email@hidden>
- Date: Thu, 3 Feb 2011 16:41:37 +1100
Hi,
We have a client program that's intermittently getting EXC_BAD_ACCESS. I've tracked it down to some code that's pushing a value onto the stack, but vmmap(1) seems to say it's mapped properly, so I'm wondering (1) if I'm reading the code correctly, (2) if I'm reading vmmap correctly, and (3) if there's another reason why EXC_BAD_ACCESS would pop up? Oh and (4) if there's an XCode tool I should use instead of vmmap to show me whether the memory's mapped and what thread owns it.
Our program is a wxWidgets program compiled against their Carbon port, running on OSX 10.6.6. This is what I've managed to pull out of XCode/gdb so far:
Program received signal: “EXC_BAD_ACCESS”.
(gdb) info threads
32 0x0046e92d in Mo::GLOffscreen::overlay (this=0x2cc8e6d0, src=@0xb0827b70, background=@0xb0827b90, image=@0xb0827c70) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/DibRenderer/GLOffscreen.cpp:964
31 0x9895a0fa in mach_msg_trap ()
* 30 0x00fd1201 in wxThreadModule::~wxThreadModule (this=0x3ed9730) at ../wxWidgets-2.8.10/src/mac/carbon/thread.cpp:1630
29 0x02f82400 in HorizontalFilter ()
21 "com.apple.CFSocket.private" 0x989790c6 in select$DARWIN_EXTSN ()
14 0x9895a14e in semaphore_timedwait_trap ()
13 0x9895a14e in semaphore_timedwait_trap ()
12 0x9895a14e in semaphore_timedwait_trap ()
11 0x9895a14e in semaphore_timedwait_trap ()
10 0x9895a14e in semaphore_timedwait_trap ()
9 0x9895a14e in semaphore_timedwait_trap ()
8 0x9895a14e in semaphore_timedwait_trap ()
7 0x9895a14e in semaphore_timedwait_trap ()
6 0x9895a14e in semaphore_timedwait_trap ()
5 0x9895a14e in semaphore_timedwait_trap ()
4 0x9895a14e in semaphore_timedwait_trap ()
2 "com.apple.libdispatch-manager" 0x98980982 in kevent ()
1 "com.apple.main-thread" 0xffff0264 in __spin_lock ()
(gdb) info stack
#0 0x00fd1201 in wxThreadModule::~wxThreadModule (this=0x3ed9730) at ../wxWidgets-2.8.10/src/mac/carbon/thread.cpp:1630
#1 0x00fcea12 in wxSemaphore::Wait (this=0x3ed9690) at thrimpl.cpp:304
#2 0x0025f1fc in Mo::TextWrapper::wrap (this=0x3ab5a90, text=@0xb0723ac4, width=109, font=@0xb07239d8, maxLineHeightPx=@0xb0723ab4) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/Widgets/TextWrapper.cpp:103
#3 0x0025f336 in Mo::TextWrapper::wrap (this=0x3ab5a90, text=@0xb0723ac4, widthMM=38.571426391601562, font=@0xb0723abc, scale=1, fullWidthPx=@0xb0723ab8, maxLineHeightPx=@0xb0723ab4) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/Widgets/TextWrapper.cpp:82
#4 0x0019ec27 in Mo::DibRenderer::drawText (this=0x2cce93a0, pic=0x2bf9bdb0, mmToPxScale=11.808080808080808, out=0x0, clip=@0xb0723bb8) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/DibRenderer/DibRenderer.cpp:523
#5 0x000aa98d in MoText::renderToCanvasTextLayer (this=0x2bf9bdb0, dib=0x2cce93a0, scaling=11.808080808080808, drawEdgeWarning=true, clip=@0xb0723bb8) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/Model/PageObjects/Text.cpp:169
#6 0x0021dcc3 in Mo::Export::ThumbnailTextRenderer::renderText (this=0x2cce93a0, image=@0xb0723c70, obj=0x2bf9bdb0, pgNr=2) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/Export/ThumbnailTextRenderer.cpp:35
#7 0x0021c08c in Mo::Export::ThumbnailProcessor::processRenderedPage (this=0x2ccde990, pageNr=2, page=@0x1fc5d798, image=@0x2eeeadc0) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/Export/ThumbnailProcessor.cpp:70
#8 0x002194b1 in Mo::Export::RenderedPageWorkItem::process (this=0x2eee2180) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/Export/RenderedPageWorkItem.cpp:60
#9 0x00222215 in Mo::AsyncWorkQueueThread::processWorkItem (this=0x1e952620) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/WorkQueue/AsyncWorkQueueThread.cpp:108
#10 0x00222505 in Mo::AsyncWorkQueueThread::Entry (this=0x1e952620) at /Users/jams/build/mom-6-0/MomentoBuild/../Momento/WorkQueue/AsyncWorkQueueThread.cpp:63
#11 0x00fcfe3a in wxThreadInternal::MacThreadStart (parameter=0x1e952620) at ../wxWidgets-2.8.10/src/mac/carbon/thread.cpp:1062
#12 0x96e9885a in PrivateMPEntryPoint ()
#13 0x9898785d in _pthread_start ()
#14 0x989876e2 in thread_start ()
(gdb) info frame
Stack level 1, frame at 0xb07238c0:
eip = 0xfcea12 in wxSemaphore::Wait() (thrimpl.cpp:304); saved eip 0x25f1fc
called by frame at 0xb0723990, caller of frame at 0xb0723880
source language c++.
Arglist at 0xb07238b8, args:
Locals at 0xb07238b8, Previous frame's sp is 0xb07238c0
Saved registers:
ebx at 0xb07238b4, ebp at 0xb07238b8, eip at 0xb07238bc
this=0x3ed9690(gdb) disassemble
Dump of assembler code for function _ZN11wxSemaphore4WaitEv:
0x00fce9b2 <_ZN11wxSemaphore4WaitEv+0>: push p
0x00fce9b3 <_ZN11wxSemaphore4WaitEv+1>: mov %esp,p
0x00fce9b5 <_ZN11wxSemaphore4WaitEv+3>: push x
0x00fce9b6 <_ZN11wxSemaphore4WaitEv+4>: sub $0x34,%esp
0x00fce9b9 <_ZN11wxSemaphore4WaitEv+7>: call 0xfce9be <_ZN11wxSemaphore4WaitEv+12>
0x00fce9be <_ZN11wxSemaphore4WaitEv+12>: pop x
0x00fce9bf <_ZN11wxSemaphore4WaitEv+13>: mov 0x8(p),x
0x00fce9c2 <_ZN11wxSemaphore4WaitEv+16>: mov (x),x
0x00fce9c4 <_ZN11wxSemaphore4WaitEv+18>: test x,x
0x00fce9c6 <_ZN11wxSemaphore4WaitEv+20>: jne 0xfcea05 <_ZN11wxSemaphore4WaitEv+83>
0x00fce9c8 <_ZN11wxSemaphore4WaitEv+22>: lea 0x55e3e(x),x
0x00fce9ce <_ZN11wxSemaphore4WaitEv+28>: mov x,0x10(%esp)
0x00fce9d2 <_ZN11wxSemaphore4WaitEv+32>: lea 0x559ea(x),x
0x00fce9d8 <_ZN11wxSemaphore4WaitEv+38>: mov x,0xc(%esp)
0x00fce9dc <_ZN11wxSemaphore4WaitEv+42>: lea 0x5f29b(x),x
0x00fce9e2 <_ZN11wxSemaphore4WaitEv+48>: mov x,0x8(%esp)
0x00fce9e6 <_ZN11wxSemaphore4WaitEv+52>: movl $0x12e,0x4(%esp)
0x00fce9ee <_ZN11wxSemaphore4WaitEv+60>: lea 0x55a16(x),x
0x00fce9f4 <_ZN11wxSemaphore4WaitEv+66>: mov x,(%esp)
0x00fce9f7 <_ZN11wxSemaphore4WaitEv+69>: call 0xf29dc4 <_Z10wxOnAssertPKwiPKcS0_S0_>
0x00fce9fc <_ZN11wxSemaphore4WaitEv+74>: movl $0x1,-0xc(p)
0x00fcea03 <_ZN11wxSemaphore4WaitEv+81>: jmp 0xfcea15 <_ZN11wxSemaphore4WaitEv+99>
0x00fcea05 <_ZN11wxSemaphore4WaitEv+83>: mov 0x8(p),x
0x00fcea08 <_ZN11wxSemaphore4WaitEv+86>: mov (x),x
0x00fcea0a <_ZN11wxSemaphore4WaitEv+88>: mov x,(%esp)
0x00fcea0d <_ZN11wxSemaphore4WaitEv+91>: call 0x1030bac <dyld_stub__ZN19wxSemaphoreInternal4WaitEv>
0x00fcea12 <_ZN11wxSemaphore4WaitEv+96>: mov x,-0xc(p)
0x00fcea15 <_ZN11wxSemaphore4WaitEv+99>: mov -0xc(p),x
0x00fcea18 <_ZN11wxSemaphore4WaitEv+102>: add $0x34,%esp
0x00fcea1b <_ZN11wxSemaphore4WaitEv+105>: pop x
0x00fcea1c <_ZN11wxSemaphore4WaitEv+106>: leave
0x00fcea1d <_ZN11wxSemaphore4WaitEv+107>: ret
End of assembler dump.
(gdb) info registers
eax 0x0 0
ecx 0xffffffff -1
edx 0x2ce2b9e4 753056228
ebx 0x3ab5bf4 61561844
esp 0xb0723880 0xb0723880
ebp 0xb07238b8 0xb07238b8
esi 0xaa936 698678
edi 0x4000000 67108864
eip 0xfcea12 0xfcea12 <wxSemaphore::Wait()+96>
eflags 0x10246 66118
cs 0x17 23
ss 0x1f 31
ds 0x1f 31
es 0x1f 31
fs 0x1f 31
gs 0x37 55
So it looks to me that the program crashes in thread 30 while it's executing
mov x, -0xc(p)
ebp - 0xc = 0xc07238ac I think. vmmap(1) says:
Stack b0723000-b0725000 [ 8K] rw-/rwx SM=COW thread 15
I'm a bit confused: does vmmap show different thread numbers than XCode? And also, that memory region looks mapped, so have I got the wrong memory region, or is there another reason why EXC_BAD_ACCESS would happen?
Thanks,
James. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden