[gambit-list] executable works, loadable module segfaults

REPLeffect repleffect at gmail.com
Fri Sep 28 06:56:09 EDT 2012

Alas I can claim no haughty inspiration... :-D

The conversion code is pretty much a blatant ripoff of Marc's code for
converting from Qt
QStrings from the "Guide" source code.  You can see it in the lib/guide
directory in the Gambit source code (in _guide.scm, guide.cpp, guide .h,
etc)...I actually started having the problem when using that same code
to convert QStrings.  At the time I didn't realize that it was a
platform-specific problem, and since it worked fine when statically compiled
into an executable, I wondered if it had something to do with some strange
issue with dynamic binding and the fact that QStrings are implicitly shared.
So I tried to do it with std::string, and lo and behold it has the same problem.

I think the #f in (c-define-type string "string" "string_to_SCMOBJ"
"SCMOBJ_to_string" #f) is actually right in this case.  That's the way
it was in Marc's QString code, and
I think it is because the string object is being passed by value, not
by a pointer, so
I think the cleanup will occur automatically in that case (the QStrings were
being passed the same way in the original code).

I already did printf's in the conversion code, and I also rebuilt Gambit with
--enable-debug and stepped through what I could.  I could never get it to
trace throught the ___alloc_scmobj() function on Windows, however (not
sure why).


On 9/28/12, Mikael <mikael.rcv at gmail.com> wrote:
> What inspired you to the particular design of string_to_SCMOBJ (things like
> ___CTOS_HEAP_OVERFLOW_ERR+arg_num;)?
> 2012/9/28 Mikael <mikael.rcv at gmail.com>
>> Just to start, are you sure that when you return that string, that it
>> remains on the C heap somewhere all until your string_to_SCMOBJ procedure
>> digests it?
>> I mean, if it's on the stack, then probably it's overwritten by the
>> subsequent C procedure call to string_to_SCMOBJ, which consumes stack
>> space
>> (the unsigned int and ___SCMOBJ in string_to_SCMOBJ should take the first
>> positions of stack space that f1b_hello previously occupied, and thus
>> destroy the structure?).
>> If it had been a char* constant you had returned instead, I suppose the C
>> compiler would have put it in some separate, reserved area.
>> Well just a wild guess.
>> What about adding Lots of debug printf:s in string_to_SCMOBJ as to check
>> that it produces the right thing.
>> Last, in your type definition (c-define-type string "string"
>> "string_to_SCMOBJ" "SCMOBJ_to_string" #f) you use #f for release function
>> i.e. afaik free()?
>> That's not the right thing right, you'd want C++' delete or sth..?
>> Also why is not the string type you use pointered? Please correct me on
>> this one.
>>  Brgds
>> 2012/9/28 REPLeffect <repleffect at gmail.com>
>>>  I came across a strange behavior with Gambit Scheme on Windows (XP, in
>>> this case).  I wrote a module to convert C++ std::string types to
>>> Gambit char-strings.  I wanted to use that in a loadable module.  This
>>> all works fine on Linux, but I also need to use it on Windows.  I'm
>>> using MinGW's C++ compiler (g++ version 4.6.2 -- which I also used to
>>> compile Gambit).  And I'm still on version 4.6.5 of Gambit Scheme.
>>> I've attached a zipped tar file with an example (6 files, including a
>>> build.windows script and a build.linux script).
>>> When I load the shared module in gsi on Windows XP, it segfaults in
>>> ___garbage_collect(long) -- I believe it was in the call to
>>> ___alloc_scmobj.  When I load it on Linux it works just fine.  The
>>> executable built by the scripts on both platforms works just fine.
>>> I would love to know what is causing this.  I've spent many hours
>>> trying to find the source of the problem, and finally narrowed it down
>>> to this.
>>> Any help/explanations/suggestions would be much appreciated.
>>> repleffect
>>> _______________________________________________
>>> Gambit-list mailing list
>>> Gambit-list at iro.umontreal.ca
>>> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

More information about the Gambit-list mailing list