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@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@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@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@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list