From: dcasale AT my-deja DOT com Newsgroups: comp.os.msdos.djgpp Subject: Re: My program hangs under RHIDE's debugger Date: Fri, 10 Nov 2000 21:07:40 GMT Organization: Deja.com - Before you buy. Lines: 94 Message-ID: <8uho2n$kr9$1@nnrp1.deja.com> References: <8ueodf$5ep$1 AT nnrp1 DOT deja DOT com> <9743-Thu09Nov2000224218+0200-eliz AT is DOT elta DOT co DOT il> <8ufgue$reg$1 AT nnrp1 DOT deja DOT com> <9003-Fri10Nov2000120410+0200-eliz AT is DOT elta DOT co DOT il> NNTP-Posting-Host: 199.249.234.30 X-Article-Creation-Date: Fri Nov 10 21:07:40 2000 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) X-Http-Proxy: 1.1 x71.deja.com:80 (Squid/1.1.22) for client 199.249.234.30 X-MyDeja-Info: XMYDJUIDdcasale To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com What happened to my post!? That's screwy... Thanks DejaNews. :-p~ In article <9003-Fri10Nov2000120410+0200-eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com wrote: > > From: dcasale AT my-deja DOT com > > Newsgroups: comp.os.msdos.djgpp > > Date: Fri, 10 Nov 2000 00:53:36 GMT > > > > Guess that means I need to copy my build environment to a separate > > drive, eh? ^^;;; > > It would be interesting to see if this also explains the time > slow-down... No, that's not the cause. I was only running my program from the JAZZ disk for about the past day or so, before I figured out what the problem was. The slowdown's been there since the beginning. > > > > > Why did you insert PUSHF and POPF? They are not needed for > > > > > __dpmi_int calls; I suggest to remove them. > > > > > > > > Because another programmer who was working on this code before > > > > me found that with _some_ __dpmi_int int 13h calls, interrupts > > > > were mysteriously turned off after the call returned. That > > > > _may_ be the reason my system clock is slowing down. > > > > > > Something must be turning interrupts back on, or else the keyboard > > > would stop working as well, and you will have a totally wedged > > > system. > > > > Yeah, I know. He says that the internal code for INT 21h (which I > > also use) checks to see if interrupts are turned off, and turns > > them back on if necessary. But, he says that if a certain error > > condition occurs during an INT 13h call, the function jumps to a > > spot in the return code which _misses_ the opcode to turn > > interrupts back on. > > One possible cause of interupts getting subtly disabled is when you > run a program under a debugger with CWSDPMI as your host. In this > case, any code, including library functions, that uses __dpmi_int to > call any of the DPMI services hooked by the DJGPP debug interface will > return with interrupts disabled. This is because CWSDPMI implements > the Int 31h not quite as the DPMI spec says (I forget the details). Well, I've seen the slowdown when running a release-mode version of the executable (with debugging printfs as necessary) with compression turned on. Turning compression off makes the slowdown disappear. That's why I said it was wierd. > Note that this can only happen under a debugger, and is usually of > concern only for programs which disable and enable interrupts. See above. > For the rest of this story, including some discussion, see this > message (this URL is one long line): > > http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp- workers/1999/12/30/02:54:16 > > You can browse the whole thread "Re: GDB, DOS 6.22, CWSDPMI and > Interrupts" (posted to djgpp-workers) on DJ's server, if you want to > know more. Not right now, but I might look at it later. :-) Here's an update on the situation, though. I was able to get my compression program working with Nate Eldredge's YAMD (Yet Another Malloc Debugger). My program has a loop which allocates some bytes, allocates some more bytes, then deallocates both. The loop executes without any trouble several times, then fails on an allocation. Any ideas why that would happen? Is there a DJGPP equivalent to the Microsoft _fheapmin call that I don't know about, that might solve this problem? I'll post a snippet from YAMD's symify'ed log file if you'd like, but it's kind of large. One of the things that I noticed was that it wasn't malloc'ing in the same spot. One time it would malloc at 0x272eff4 and 0x2732fd8 (and deallocate them both properly). The next time it would malloc at 0x2736ff4 and 0x273afd8 (again, deallocating them both properly). There's nothing else in between these two allocations and deallocations in the log file, either, and they both happen to be 12 bytes and 40 bytes. So why didn't the malloc's happen in the same spot? Damon Casale, damon AT WRONG DOT redshift DOT com I'm in a heap o' trouble... ;-p Sent via Deja.com http://www.deja.com/ Before you buy.