Segfault on shutdown

I pushed the code to GitHub. If you check out the jsonquery branch for CloudKit, you will see it. The direct link is here:

http://github.com/jcrosby/cloudk...

The spots where CloudKit interacts with Johnson are:

1. Setting up the environment: http://github.com/jcrosby/cloudk...

2. Filtering using JSONQuery: http://github.com/jcrosby/cloudk...

You can run the specs with rake or with spec -c spec to see the segfault on shutdown. This could be due to my misuse of the library, but I thought it would be helpful to have a few other eyes on it too.

It's not you. :) We're definitely having some problems with double
frees on runtime shutdown. Could you possibly run your spec process
under GDB and attach the backtrace to this ticket? You can look in
johnson/lib/tasks/testing.rake for an example if you don't run under
GDB often.

Also, are you using the 1.1 release of Johnson (the one from RubyForge)?

One more bit of info: the only spec that exercises Johnson is in spec/resource_spec.rb and this spec runs on its own without errors. As mentioned above, the problem only happens when enough of the specs are run to surpass some point near or just below 259 specs.

Thanks for the GDB tip. I'll run using that and post output here.

Regarding 1.1, I am using the latest SHA from GitHub installed using the rake task: http://github.com/jbarnette/john...

(I could not get the rubyforge version to install due to the Manifest.txt error reported separately here.)

Running the following simply opens the gdb prompt. Running it without gdb produces the segfault. Is there some other argument I should be passing to gdb?

gdb --args /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -I"/Library/Ruby/Gems/1.8/gems/rspec-1.1.12/lib" "/Library/Ruby/Gems/1.8/gems/rspec-1.1.12/bin/spec" "spec/ext_spec.rb" "spec/flash_session_spec.rb" "spec/memory_table_spec.rb" "spec/oauth_filter_spec.rb" "spec/oauth_store_spec.rb" "spec/openid_filter_spec.rb" "spec/openid_store_spec.rb" "spec/rack_builder_spec.rb" "spec/request_spec.rb" "spec/resource_spec.rb" "spec/service_spec.rb" "spec/store_spec.rb" "spec/uri_spec.rb" "spec/user_store_spec.rb" "spec/util_spec.rb"

After issuing "run" at the gdb prompt, here is the output:

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x001b80a8 0x00655887 in JS_DHashTableOperate (table=0x1b808c, key=0x162f510, op=JS_DHASH_REMOVE) at jsdhash.c:578 578 JS_ASSERT(op == JS_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0);

After you "run", run "bt" and attach the backtrace. Thanks! :)

~ j. // mobile. bad spelling, etc.

On Apr 6, 2009, at 1:48 PM, Lighthouse no-reply@lighthouseapp.com
wrote:

Here you go:

296 examples, 0 failures, 27 pending JS engine warning: leaking GC root 'JSScriptProxy' at 0x1e0e040 JS engine warning: 1 GC root remains after destroying the JSRuntime at 0x1b8000.

               This root may point to freed memory. Objects reachable
               through it have not been finalized.

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x001b80a8 0x00655887 in JS_DHashTableOperate (table=0x1b808c, key=0x1e0e040, op=JS_DHASH_REMOVE) at jsdhash.c:578 578 JS_ASSERT(op == JS_DHASH_LOOKUP || RECURSION_LEVEL(table) == 0); (gdb) bt #0 0x00655887 in JS_DHashTableOperate (table=0x1b808c, key=0x1e0e040, op=JS_DHASH_REMOVE) at jsdhash.c:578 #1 Better Exception Hierarchy 0x006796b3 in js_RemoveRoot (rt=0x1b8000, rp=0x1e0e040) at jsgc.c:1502 #2 Hardcoded Stack and Heap Sizes 0x0063630e in JS_RemoveRootRT (rt=0x1b8000, rp=0x1e0e040) at jsapi.c:1888 #3 Nasty Build Process 0x0062624c in finalize (proxy=0x1e0e040) at /Library/Ruby/Gems/1.8/gems/johnson-1.1.0/ext/spidermonkey/ruby_land_proxy.c:463 #4 Build Cleanly on Something Besides OS X 0x000ee8aa in rb_gc_call_finalizer_at_exit () #5 Support Windows 0x000d1f26 in ruby_native_thread_kill () #6 Implement <=> for Enumerable Proxies 0x000e27bb in ruby_cleanup () #7 String/Symbol Agnosticism 0x000e2872 in ruby_stop () #8 Exception Handling in Proxy#call 0x000e8fe6 in ruby_run () #9 Exception Handling in Proxy#each 0x00001fff in main ()