[Starkit] FreeBSD core dumps when wrapping big files!
jcw at equi4.com
Fri Dec 15 11:40:47 CET 2006
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
More information about the Starkit