Debugging Garbage collection

Skip to first unread message


Nov 25, 2012, 2:05:57 AM11/25/12

I'm getting intermittent EXC_BAD_ACCESS errors during garbage collection (I think it's garbage collection) in the machine::objectFixed() function.  Can anyone offer any strategies to debug this type of problem?  The stack trace is as follows:

Thread 5, Queue : (null)
#0 0x0055e65e in vm::objectFixed(vm::Thread*, vm::Object*) [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/machine.h:2120
#1 0x0055e65b in isFixed at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:2754
#2 0x004eed7c in update3 [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1070
#3 0x004eed67 in void* vm::mask<void>(void*) [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1105
#4 0x004eed36 in update at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1187
#5 0x004ef327 in collect at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1309
#6 0x004ee7ec in collect [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1492
#7 0x004ee7d5 in visit at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1666
#8 0x004ae109 in visitStack [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/compile.cpp:7959
#9 0x004adeb5 in visitObjects at /Users/shannah/src/iOSPortAvian/avian/src/compile.cpp:8942
#10 0x0055ddc5 in visitRoots at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:294
#11 0x0055dfda in visitRoots at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:4708
#12 0x004f07e4 in collect2 [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1673
#13 0x004f04c9 in collect [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1737
#14 0x004f04c9 in collect at /Users/shannah/src/iOSPortAvian/avian/src/heap.cpp:1895
#15 0x00561b17 in doCollect at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:2840
#16 0x00563290 in vm::collect(vm::Thread*, vm::Heap::CollectionType) at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:4620
#17 0x0056352d in vm::allocate3(vm::Thread*, vm::Allocator*, vm::Machine::AllocationType, unsigned int, bool) at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:3519
#18 0x005644e7 in vm::allocate2(vm::Thread*, unsigned int, bool) [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:3448
#19 0x005644bc in vm::pad(unsigned int) [inlined] at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:1853
#20 0x00564489 in vm::makeByteArray(vm::Thread*, unsigned long) at /Users/shannah/src/iOSPortAvian/avian/src/machine.cpp:2233
#21 0x004b0d8c in makeBlankArray at /Users/shannah/src/iOSPortAvian/avian/src/compile.cpp:2859
#22 0x001946ad in java/io/InputStream.skip(J)J ()
#23 0x00194165 in java/io/FilterInputStream.skip(J)J ()
#24 0x0017aad4 in com/codename1/ui/util/Resources.readMultiImage(Ljava/io/DataInputStream;Z)Lcom/codename1/ui/Image; ()
#25 0x0017a749 in com/codename1/ui/util/Resources.readMultiImage(Ljava/io/DataInputStream;)Lcom/codename1/ui/Image; ()
#26 0x00179d7b in com/codename1/ui/util/Resources.createImage()Lcom/codename1/ui/Image; ()
#27 0x00177673 in com/codename1/ui/util/Resources.openFileImpl(Ljava/io/InputStream;)V ()
#28 0x00177332 in com/codename1/ui/util/Resources.openFile(Ljava/io/InputStream;)V ()
#29 0x00177260 in com/codename1/ui/util/Resources.<init>(Ljava/io/InputStream;)V ()
#30 0x001784f2 in com/codename1/ui/util/;)Lcom/codename1/ui/util/Resources; ()
#31 0x001781cc in com/codename1/ui/util/Resources.openLayered(Ljava/lang/String;)Lcom/codename1/ui/util/Resources; ()
#32 0x000750c4 in com/codename1/demos/kitchen/Themes$3.actionPerformed(Lcom/codename1/ui/events/ActionEvent;)V ()
#33 0x00176a65 in com/codename1/ui/util/EventDispatcher.fireActionSync([Lcom/codename1/ui/events/ActionListener;Lcom/codename1/ui/events/ActionEvent;)V ()
#34 0x001765a2 in com/codename1/ui/util/EventDispatcher.fireActionEvent(Lcom/codename1/ui/events/ActionEvent;)V ()
#35 0x000ab23d in com/codename1/ui/Button.fireActionEvent(II)V ()
#36 0x000ab327 in com/codename1/ui/Button.released(II)V ()
#37 0x000ab5f2 in com/codename1/ui/Button.pointerReleased(II)V ()
#38 0x000d4b62 in com/codename1/ui/Form.pointerReleased(II)V ()
#39 0x000b51c9 in com/codename1/ui/Component.pointerReleased([I[I)V ()
#40 0x000cc1cc in com/codename1/ui/Display.handleEvent([I)V ()
#41 0x000c99df in com/codename1/ui/Display.edtLoopImpl()V ()
#42 0x000c95cc in com/codename1/ui/Display.mainEDTLoop()V ()
#43 0x0015a198 in com/codename1/ui/ ()
#44 0x00083c58 in com/codename1/impl/ ()

The function line of code is:

inline bool

objectFixed(Thread*, object o)


  return (alias(o, 0) & (~PointerMask)) == FixedMark;


Any help much appreciated.



Dec 2, 2012, 4:56:09 PM12/2/12
Any ideas on this at all?  Even the smallest tip...


Joel Dice

Dec 2, 2012, 5:18:20 PM12/2/12
On Sun, 2 Dec 2012, shannah wrote:

> Any ideas on this at all? �Even the smallest tip...

The stack trace you provided certainly indicates that the Java heap is
being corrupted somehow, leading to an invalid memory access during
garbage collection. That could be due to either a bug in the VM or a bug
in JNI code provided by your app or a library it depends on. If your app
(or library) uses JNI, that's the first place I would look, e.g. to ensure
that a buffer is not being freed prematurely.

If there's no JNI code involved, it's probably a bug in the VM. There's
no simple recipe for tracking such bugs down. I usually use a combination
of GDB, Valgrind, extra System.gc() calls, and print statements to narrow
the problem down as much as possible. For example, you can do a sort of
binary search through the code by adding System.gc() calls strategically
to determine the latest point at which GC succeeds (i.e. the latest
point the heap was pristine) before things go awry. No specific strategy
works for every case, though.

If possible, try to reduce the scenario to something simple,
non-interactive, and (mostly) reproduceable, which will make the debug
cycle shorter.

I'd be willing to try to debug it myself if you can send me a test case.
However, my Mac was stolen recently, and it will be a while before I have
a new one, so you may have to wait a while if it's only reproducable on
Mac or iOS.
> --
> You received this message because you are subscribed to the Google Groups
> "Avian" group.
> To view this discussion on the web visit
> To post to this group, send email to
> To unsubscribe from this group, send email to
> For more options, visit this group at

Steve Hannah

Dec 2, 2012, 5:47:13 PM12/2/12
Thanks for the reply, Joel.  There is quite a bit of JNI code so I suspect the problem is there rather than in the VM.

I'll try your strategy of using System.gc() calls to track it down.

Sorry to hear about your Mac being stolen.  That sucks.  Keep up the great work on this project.  

Btw, I have posted an article with my experience with this project on my blog, at, if you're interested.

Best regards


For more options, visit this group at

You received this message because you are subscribed to the Google Groups "Avian" group.
To post to this group, send email to
To unsubscribe from this group, send email to

For more options, visit this group at

Steve Hannah
Web Lite Solutions Corp.

Steve Hannah

Dec 2, 2012, 7:26:33 PM12/2/12
That was money advice!  Using System.gc() calls, I was able to track the problem down to the initial call of the main() method.  I retrieved a method id in JNI for my entry point's main() method which requires a String array as an argument.  But I didn't pass anything when I called the method using CallStaticVoidMethod().  The method call worked, but apparently it corrupted the heap so that when Garbage collection started to run, it just died.

Thanks so much for your help.

Reply all
Reply to author
0 new messages