[Starkit] FreeBSD core dumps when wrapping big files!

[Jean-Claude Wippler]

Joey Mukherjee wrote:

> Ok, I have tried everything in trying to get a FreeBSD starkit to  
> work and have finally discovered my problem.
>
> I have a file which is roughly 80mb that I include in the starkit.   
> With this file, I can never get the final "sdx.kit wrap" to work -  
> it will just dump core.  This 80mb file is actually a zip file that  
> if I unzip it, it works fine so its not the size of the kit I am  
> creating, just the size of the individual file.
>
> I do this same wrapping on a Solaris, Mac, Linux, and Windows box  
> and they all have .zip's inside which are all bigger than the  
> 80mb.  Just FreeBSD fails...  I have tried with 8.4/8.5 from the  
> website as well as creating them myself.

This is very strange, the 80 Mb should not matter.  All I can think  
of is a missing "fconfigure -translation binary" somewhere, i.e. that  
there is a data contents sensitivity somewhere (or perhaps a null- 
byte or some other encoding quirk).

You may have to binary-search-split the problematic file to determine  
exactly when it fails and when it still works.  Again, I can't think  
of a reason why *size* in itself would be a problem.

> Does anyone have any ideas on what else I could do to make this  
> work?  I tried making a Tclkit-Lite with the kitgen, but it does  
> not work on FreeBSD?  In case this is an easier problem to solve,  
> kitgen builds all of Tcl, but the install fails with:
>
> Making directory /build/lib
> mkdir: /build: Permission denied
> *** Error code 1
>
> I change the makefile.include to remove the "$(shell pwd)" and hard  
> code the directory, I get a little further:
[...]

I've just checked in some changes to kitgen to better support *BSD  
OS'es.  One crucial bit of info is that you have to use GNU make,  
i.e. "gmake", not "make".  A quick test on a FreeBSD machine on the  
SourceForge compile farm appears to work.

> Back to the tclkit, I am attaching a "gdb where" in case it helps,  
> but it is long.
[...]
> #0  0x28306026 in memcpy () from /lib/libc.so.6
> #1  0x080d4222 in Tcl_AppendObjToObj ()
> #2  0x080d4356 in Tcl_AppendObjToObj ()
> #3  0x080d40e0 in Tcl_AppendObjToObj ()
> #4  0x080e2280 in TclPtrSetVar ()
> #5  0x08097faf in TclIncrObj ()
> #6  0x08095e9b in TclCompEvalObj ()
> #7  0x080cf4dd in TclObjInterpProc ()
> #8  0x080cf021 in TclObjInterpProc ()
> #9  0x0806897f in TclEvalObjvInternal ()
> #10 0x08068b5d in Tcl_EvalObjv ()
> #11 0x0806946b in Tcl_EvalObjEx ()
> #12 0x08065665 in TclKit_AppInit ()
> #13 0x080aaf2f in Tcl_GetChannelHandle ()
> #14 0x080b0a70 in TclCopyChannel ()
> #15 0x080b0002 in TclCopyChannel ()
> #16 0x080afc40 in TclCopyChannel ()
> #17 0x080b7971 in TclCrossFilesystemCopy ()
[...]

This seems mixed up: how can #12 come up so high in this traceback?

You might get further with Tclkit Lite, because it's easier to build  
a version with symbols so gdb can be more verbose (and accurate?) in  
its tracebacks.

-jcw