More often then not, when I had problems like that with Icarus Verilog it turned out to be different handling (by the O/S) of dynamically allocated memory. One or the other (I forget which) will leave random data in malloc'ed memory. If malloc'ed data is not initialized, this can lead to code down-stream getting confused and crashing.
Dan McMahill wrote: > I was completely unable to reproduce this under linux or netbsd. I also > tried things like running electricfence on netbsd and was never able to > reproduce the crash there. Under windows though it always happens. The > output of gdb was totally useless to me although maybe someone else > would have better luck. > > I think we have 2 likely reasons for the crash. > > 1) There are some #ifdef WIN32 in a small number of places in the code > that has to do with rendering so we do have a slightly different code > path within gerbv. [*] > > 2) Bugs in gtk/gdk for windows. > > Unfortunately I don't have any more time to put into it and I don't have > a sufficient cairo and gdk clue to be very effective anyway. > > -Dan > > [*] While looking for #ifdef WIN32, I found some totally inappropriate > use of WIN32 and __sparc__ in the csv parser. We should fix that. > There is code that looks for the processor (via __sparc__) and then > makes assumptions about libc functions and other os, but not processor, > dependent things. > > > _______________________________________________ > geda-user mailing list > [EMAIL PROTECTED] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
