At Wed, 8 Jul 2015 18:23:32 -0700 (PDT), Scott Bell wrote: > On Wednesday, July 8, 2015 at 4:05:20 PM UTC-7, Scott Bell wrote: > > On Wednesday, July 8, 2015 at 3:48:22 PM UTC-7, neil wrote: > > > Does adding the executable pathname to the `gdb` command line (i.e., > > > format `gdb EXECUTABLE-FILE CORE-FILE`) give you the symbols? > > > > Ah, of course. Yes, now we're getting somewhere: > > > > ... > > #6 0x000000080153e004 in strlen () from /lib/libc.so.7 > > #7 0x0000000800a72bf3 in scheme_make_byte_string_without_copying () > > from /usr/local/lib/libracket3m-6.1.1.so > > #8 0x0000000800ade3f2 in c_to_scheme () > > from /usr/local/lib/libracket3m-6.1.1.so > > #9 0x0000000800adee02 in ffi_do_call () > > from /usr/local/lib/libracket3m-6.1.1.so > > ... > > > > That certainly points me in the direction of a bad FFI call. > > When I say bad FFI call, I'm leaving open the possibility that > the issue may be in the FFI machinery as well as in our source, > but I should point out that the minimal amount of FFI code > that we have is years old and has been running without issue. > We first observed this crash only a few months ago.
Do you know what foreign function is being called? If so, does it return a GC-managed string pointer, or is it one that's outside the GC's management? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
