On Thursday, July 9, 2015 at 12:27:26 AM UTC-7, Matthew Flatt wrote:
> 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?
I don't know which foreign function is being called, but
we don't have a lot of them, and they're all to either
system or third-party libraries. Based on the stack trace
of the crash, I'm assuming the relevant calls are the
ones that return a byte string, so here they are:
(_fun _string _string -> _bytes)
The return value here is 'char *', and may be NULL on
failure. Racket seems to handle this correctly based
on manual testing and returns #f in the failure case.
(_fun [EVP_MD : _fpointer = (evp-sha1)]
[key : _bytes]
[key_len : _int = (bytes-length key)]
[data : _bytes]
[data_len : _int = (bytes-length data)]
[md : (_bytes o 20)]
[md_len : (_ptr o _uint)]
-> _bytes
-> md)
This is the function signature for HMAC from libcrypto,
and in fact this is in Racket at:
web-server-lib/web-server/stuffers/hmac-sha1.rkt
The return value should be the same pointer passed in
as `md` or NULL on failure.
So it looks like one call has callee allocated memory, and
the other is allocated by Racket using the (_bytes o n)
custom function type. I'm not sure whether or not the
latter is GC-managed.
--
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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
