On Wed, Jul 15, 2009 at 01:59:19AM +0200, Roland Mainz wrote:
> I don't know... it was never tested like this (and I don't know what
> happens if you "only" update { lishell, libcmd, libdll, libast } (that
> are the core libraries)). Splicing the tarball into pieces _may_ ruin
> the system but I am not sure.
> What I know is that this tarball should compile SFWNV+OS/Net on a
> Solaris Neavada machine without problems...
Okay, thanks.
> > This doesn't reproduce for me on sparc -- either on an M5000 running build
> > 108 or on a V880 running build 116. It does reliably reproduce back on my
> > build 118 x86 box (after changing sparcv7 to i86
>
> Did you use VMDEBUG=a in the environment (that _may_ provoke the crash
> more likely...) ?
I did.
> If it doesn't work it _may_ (or better: I am guessing...) help to use a
> current working directory with a different length (e.g.
> /tmp/dduval/kshfftw2crash/ or /tmp/dduval/xyz/) ...
I'll give that a shot.
> > So I can't help with the bcheck thing for you.
>
> Any idea who may be able to help ?
You could ask on tools-compilers about what might be wrong for you with
bcheck, I think, though I was thinking more about the specifics of this
dump -- if it's not reproducible on any available sparc boxes, then no
one's going to be able to use bcheck to track it down. I'll see if the
path length makes a difference.
Thanks,
Danek
