[gambit-list] executable works, loadable module segfaults

REPLeffect repleffect at gmail.com
Sat Sep 29 03:20:55 EDT 2012

Well, I have no one to blame for this but myself.

I noticed I was using g++ 4.4.5 on Linux (where the code worked fine).
 So I decided to try that version on Windows.  I downloded a binary
distribution of g++ for MinGW (version 4.4.5) and installed it.  I
rebuilt/reinstalled Gambit with it first, then when I tried to build
my sample program I had to take out the -fno-keep-inline-dllexport
option (because 4.4.5 didn't support that option).  I reran the test
(loaded the f2.o1 file from the interpreter), and it worked like a

I started to think it must be a problem with g++ 4.6.2 (at least this
particular MinGW build of it).  But I had remembered that it was *I*
who had suggested adding the -fno-keep-inline-dllexport option to the
build for MinGW (back in February of this year).  I don't even
remember where I saw the suggestion, but it had to do with things you
could do when the compiler was running out of memory.

Then I noticed that in one of my later posts, I'd said I was able to
compile just fine *without* the -fno-keep-inline-dllexport option.

I could hear myself saying "Oh, I wonder if that option could be
causing the problem in the first place?"  I was building a loadable
library, and I was also building Gambit with --enable-shared, so it
seemed possible.

With that in mind, I tried going back to g++ 4.6.2, and taking the
-fno-keep-inline-dllexport option out of the Gambit build and of my
test application's build.

Rebuilt, reinstalled, reran the test -- BINGO!  Works fine on 4.6.2
without that option.

So ... um ... Marc, I'd like to suggest that you remove the
-fno-keep-inline-dllexport option from the build on Windows which I
stupidly suggested you add last February :-D

There's a song by the group "Casting Crowns" called "My Own Worst
Enemy" (the author is referring to himself).

Tonight I kind of feel that way!  :-D

On 9/28/12, REPLeffect <repleffect at gmail.com> wrote:
> 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).
> repleffect
> 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