It is definitely XWin that is crashing. I seem to have had some mental block when I wrote the last message because I could swear I had said it died in 24 bit, but the text doesn't lie... I will try putting a bunch of ErrorF statements in and send the resulting log file ASAP. Thanks.
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Earle F. Philhower, > III > Sent: Monday, August 11, 2003 2:27 PM > To: [EMAIL PROTECTED] > Subject: Re: DDD dies on me > > > Howdy Andrew... > > ---------- Original Message ------------- > Subject: DDD dies on me > From: "Andrew Braverman" <[EMAIL PROTECTED]> > A while ago (beginning of June, I think), I posted a note to > this group that > .. > to figure out that the program occurred in winScaleXBitmapToWindows in > winmultiwindowicons.c. I ran three consecutive tests and two > of those three > caused a segfault in the free at the end of the procedure (actually in > mktime??? called by free). The iconData mallocs at the > beginning of the > procedure seem to align correctly with the frees at the end. The last > caused a segfault in fb24_32BltUp which is called from the > miGetImage at the > beginning of the procedure. Seeing that, I decided to try > the program in 16 > bit color and everything was fine. For the first time, I was > able to see > that this program does display its own icon on the title bar. > Does anyone > (Earle?) have any suggestions about where I should start > digging? In any > case, I will try to do a little more digging over the next week or so. > ----------------- > > A silly question, it is XWin.exe that's SEGVíng and not > DDD.exe, correct? > And what was the screen depth (8/15/16/24/32) you were running that > caused the bomb? > > Also, could you add some ErrorF()s to dump all local variables to the > /tmp/XWin.log file, as well as the pixmap->drawable structure > elements, > too? [ErrorF() works just like printf() so just > ErrorF("varX=%d\n",varX); > is all that's needed...] Posting the info it spits out > before a SEGV would > go a long way towards debugging this... > > The most likely culprit is that one of the conversions is > overwriting the > Windows icon data that it's allocated, causing bad stuff to > happen later > on. You can see how I switch between the possible formats on > effXBPP and effBPP(the Windoze BPP we're converting to), possibly not > all cases have been tested, *especially* 8-bit modes. > -- > -Earle F. Philhower, III > [EMAIL PROTECTED] > http://www.ziplabel.com > >