X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: "Rod Pemberton" Newsgroups: comp.os.msdos.djgpp Subject: Re: failure of __dpmi_set_segment_limit() problem Date: Tue, 7 Oct 2008 02:10:04 -0400 Organization: Aioe.org NNTP Server Lines: 83 Message-ID: References: NNTP-Posting-Host: mQokHQeKeRC37oD/Mq9UYg.user.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse AT aioe DOT org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 X-Newsreader: Microsoft Outlook Express 6.00.2800.1933 X-Priority: 3 X-MSMail-Priority: Normal To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com "Charles Sandmann" wrote in message news:MOadnT7eV5OCQHfVnZ2dnUVZ_g6dnZ2d AT earthlink DOT com... > "Rod Pemberton" wrote in message > news:gcbnih$6pq$1 AT aioe DOT org... > > > > I added some *inactive* code to a routine in a program I was working on > > when > > it began faulting in main(). I traced the problem to > > __dpmi_set_segment_limit() from the fault info. The limit hadn't been > > changed. __dpmi_set_segment_limit wasn't returning an error code either. > > The problem appears as __dpmi_set_segment_limit() working at first, but > > then > > the selector limit is being reset to its pre-call value. I.e., two > > back-to-back calls to __dpmi_get_segment_limit return two different > > values, > > sometimes. The following C code represents the issue, but won't run as is > > since it doesn't align main() properly. The assembly code below has been > > adjusted (.space 0x7167) for the missing code and will need to be compiled > > as "gcc -o test.exe test.s". I've tested this under RM MS-DOS v7.10 > > w/DJGPP > > v2.03 (GCC 3.4.1), DJGPP v2.04 (GCC 4.1.0), CWSDPMI v5 old and new, > > CWSDPMI > > three 6b versions, PMODETSR, etc. All combinations I've tried fail. I'm > > not sure why this only happens under these circumstances. Am I doing > > something wrong? Any help? > > Under my old toolkit (v2.03) I can't reproduce the problem, compiling the .s > file. I > suppose it's possible your toolchain makes a slightly different .exe ? > ...? That's why I tried so many combinations. I was hoping that v2.04 wouldn't exhibit the issue... Do you think it could be an issue other than DJGPP or dpmi host? Hmm, come to think of it, I didn't try it under Windows... > There is some code in crt0.S IIRC that messes with limits when dealing with > sbrk() expansion, > it's possible that a malloc() call in the first printf() reset the limit. Interesting, but the original code didn't have printf()'s... Those were just to demonstrate the setting and restoring of the limit problem. At first, I thought the issue was size related, since if you remove the .comm's space, it'll work properly again. But, it also seems to require the alignment or space prior to main. > It's been a long time, and > I have a hard time remembering details this obscure, but it's possible that > since the normal > startup code calls malloc(), if you bypass the normal startup you might need > to reset the > limit after the first call to sbrk(), or to use the crt0 flag to > automatically make it big-wrap. > At least it's someplace to start looking. > The original code did nothing special. But, I guess I could try those to see if something changes the issue. It just had a bunch of "global" and automatic space with two functions with medium sized switches... nothing over ANSI or C99 limits. > Have you tried stepping through it at an assembly instruction level with a > debugger, looking > for the DPMI segment limit change call? > No. In general, I don't use debuggers, so I'm not familiar. I'll probably poke around the problem w/C and asm a bit more before I take that path. Big leap... Thanks, Rod Pemberton