Smalltalk › Squeak › Squeak VM

sqUnixExternalPrims.c tryLoading()

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Chris Cunnington-4

sqUnixExternalPrims.c tryLoading()

The argument libName in tryLoading() in my interpreter vm build is:

$3 = "/home/ooplu/Desktop/Int_Debug//so.vm-display-X11", '\000' <repeats 608 tim
es>…

This works.

The argument libName in tryLoading() in my Cog vm build is:

$15 = "/home/ooplu/Desktop/Cog_build2/products/coglinuxht/lib/squeak/4.0-3256/vm
-display-X11\000\367\000\320\377\367p\003\373\367\000\000\000\000Xh\375\367\025\
202\376\367\020j\375\367\000\000\000\000\001\000\000\000\001\000\000\000\000\000
\000\000\272\360\371\367\000@\373\367@\255\377\377X@\373\367\260\004\373\367D@\3
73\367\026\000\000\000\t\261\337\367\000\020\364\367@\030\364\367HK\371\367\310\
335\037\b\237\334\337\367[\201\376\367\000@\373\367\210\321\037\b\367\361\371\36
7\240\255\377\377\220"...

Is there something obviously wrong with this argument path? I’m not enough of a C programmer to know. Are those numbers past the argument string garbage chars making it impossible for dlopen() to function?

dirName and moduleName go into sprintf looking fine and they come out a weird libName which does not provide a handle.

n = sprintf( libName, "%s%s%s%s”, dirName, *prefix, moduleName, *suffix );
assert(n >= 0 && n < NAME_MAX + 32);

Chris

timrowledge

Re: sqUnixExternalPrims.c tryLoading()

The bits after the \000 *shouldn’t* matter a damn to any C code unless possibly something is carefully using a length-specifying copy with the wrong length. $15 showing with all the follow-on trash seems odd but pretty much everything about gdb puzzles me.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Calm down -- it's only ones and zeros.

johnmci

Re: sqUnixExternalPrims.c tryLoading()

Assuming $15 is being shown as a 1K memory dump, versus a C String then it would be proper to dump the ascii values and then octal values for none-printables. In this case the libName would be /home/ooplu/Desktop/Cog_build2/products/coglinuxht/lib/squeak/4.0-3256/vm
-display-X11 as you terminate on the octal \000 However are you sure the parm being passed is a cString, or is it a Smalltalk string and you are just seeing the object space after the -X11. This of course would be incorrect and lucky if the trailing byte is \000

On Mon, Aug 10, 2015 at 10:46 AM, tim Rowledge <[hidden email]> wrote:

The bits after the \000 *shouldn’t* matter a damn to any C code unless possibly something is carefully using a length-specifying copy with the wrong length. $15 showing with all the follow-on trash seems odd but pretty much everything about gdb puzzles me.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Calm down -- it's only ones and zeros.

===========================================================================
John M. McIntosh <[hidden email]> https://www.linkedin.com/in/smalltalk
===========================================================================

David T. Lewis

Re: sqUnixExternalPrims.c tryLoading()

On Mon, Aug 10, 2015 at 10:53:50AM -0700, John McIntosh wrote:

>
> On Mon, Aug 10, 2015 at 10:46 AM, tim Rowledge <[hidden email]> wrote:
> >
> > The bits after the \000 *shouldn???t* matter a damn to any C code unless
> > possibly something is carefully using a length-specifying copy with the
> > wrong length. $15 showing with all the follow-on trash seems odd but pretty
> > much everything about gdb puzzles me.
> >
> Assuming $15 is being shown as a 1K memory dump, versus a C String then it
> would be proper to dump the ascii values and then octal values for
> none-printables. In this case the libName would be /home/ooplu/Desktop/Cog_
> build2/products/coglinuxht/lib/squeak/4.0-3256/vm
> -display-X11 as you terminate on the octal \000 However are you sure the
> parm being passed is a cString, or is it a Smalltalk string and you are
> just seeing the object space after the -X11. This of course would be
> incorrect and lucky if the trailing byte is \000

It's nothing to worry about one way or the other. libName is a local variable
in a function in the platform code. It is an array of char, large enough to
do whatever it needs to do. Anything after the null terminator (for the C
string) is of no interest so long as we do not overwrite the length of that
array (which we do not). It might contain left over data (the variable is
declared within the scope of a loop) or it might be just uninitialized junk.
Either way it's just some extra bytes that do not affect the code.

The debugger might display this data in various ways, but it's really just
an array of 8 bit bytes that are being interpreted as an null-terminated
string in the C tradition.

Dave