Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: "Andris Pavenis" , djgpp AT delorie DOT com Date: Mon, 23 Feb 1998 10:05:30 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Compiled RHIDE does not work with CWSDPMI (v4) In-reply-to: <6cko44$mk4$1@nnrp1.dejanews.com> Precedence: bulk "Andris Pavenis" wrote: Subject: Compiled RHIDE does not work with CWSDPMI (v4) VERY wrong conclution. > Recently I read in this newsgroup about problems running > RHIDE 1.4 under clean MS-DOS (Under Win95 all is Ok) after > compilation from sources. ^^^^^^^^^^^^ If the your compiled version of RHIDE doesn't behave in the same way than the version provided by Robert is just because you DON'T have the same libraries and tools that Robert is using. Did you applied the patchs provided with RHIDE? > I rarely use such configuration > but tests showed that it is so. I used slightly modified > sources of 1.4.1 (some bugfixes, Robert has them) so line > numbers may be aproximate. I got similar behaviour as mentioned > before. > > Here is more details: > - compiled version works under Win95 and also under QDPMI > (QEMM version 8.03) > - attempt to run it when there is no DPMI server available > (or CWSDPMI is preloaded) I'm getting faults (in infinite loop) > so only way out I have found is to reboot > > Therefore I tried to look what happens with gdb. Here is output of gdb > (the same version of idegc.exe works well under Win95): W95 doesn't check for NULL pointers and other things. > GDB is free software and you are welcome to distribute copies of it > under certain conditions; type "show copying" to see the conditions. > There is absolutely no warranty for GDB; type "show warranty" for details. > GDB 4.16 (go32), Copyright 1996 Free Software Foundation, Inc... > (gdb) run > Starting program: e:/djgpp/contrib/rhide-1.41/idegc.exe > > Program received signal SIGSEGV, Segmentation fault. > 0x101770 in strcmp () > (gdb) where > #0 0x101770 in strcmp () > #1 0xea0eb in bindtextdomain__ () > #2 0x15c1b in init_rhide__Fv () at idemain.cc:1961 > #3 0x164d8 in _GLOBAL_$I$global_argc () at idemain.cc:2308 > #4 0x104339 in __main () > #5 0xfe087 in __crt1_startup () > (gdb) q That's a problem in GetText library. And is because of some unterminated string (so strcmp walks in a memory area outside the program's range). I saw it before and is very annoying, I think it could be a bug in GetText. When I link this library with my editor I get this problem from time to time. So there is 2 options: 1) Perhaps Robert is using a patched version and he forgot to mention it. 2) That's more probable: The memory (program to be more exact) layout makes the bug visible in your EXE and not in the Robert's one. I think that's more possible because I experiment this problem just from time to time. I'm almost sure that your compiled EXE is very different to the one compiled by Robert, specially because Robert uses a linker configuration slightly modified. I tried to catch the bug, but GetText is hard to debug and each time I was able to debug it the problem didn't appear :-( The fault isn't in CWSDPMI, in fact CWSDPMI is catching the error better than Crap'95 and QDPMI. SET ------------------------------------ 0 -------------------------------- Visit my home page: http://set-soft.home.ml.org/ or http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013