Mail Archives: djgpp/1998/07/23/05:09:24
At 09:45 23.07.98 +0300, you wrote:
>None of the functions seem to be relevant to your case. I don't see
>`putpath' called anywhere in the exception-handling code, and the
>startup code can only call abort *before* `main'. As for the rest, I
>don't think you use them (`alloca' should be inlined and the library
>version never used). So I'm stumped. I hope the debugger backtrace
>will clarify things.
I think I know what's happening:
1) The NULL pointer dereference which causes the SIGSEGV and stack traceback
in plain DOS mode is ignored silently.
[Rem: I think this "feature" of the WinNT DPMI server is necessary to
run any Micro**** program at all...]
2) Shortly later there is a call to the access() function with the
NULL pointer as filename argument:
Breakpoint 1, 0x3c73 in abort ()
(gdb) backtrace
#0 0x3c73 in abort ()
#1 0x6dbc in _put_path2 ()
#2 0x6d79 in _put_path ()
#3 0x6473 in _chmod ()
#4 0x5872 in __access ()
#5 0x1d84 in main (argc=1, argv=0x57050) at test.c:29
#6 0x22be in __crt1_startup ()
(gdb)
... and here's _put_path() and abort()
>Here are some more suggestions for investigating these problems.
>
> 1) Do these problems happen with most/all DJGPP programs, or only
> with some? For example, if you write a trivial 10-liner which
> just sits in an idle loop (in a way that is still interruptible
> by Ctrl-C), does it also behave this way?
The behavior is shown by most (all?) programs of the djgpp distribution
I use (gcc, flex, bison, make ...).
10-liner 1:
#include <stdio.h>
int main(int argc, char*argv[])
{
while(1)
{
fprintf(stderr, ".");
fflush(stderr);
}
return 0;
} /* End main() */
works OK with Ctrl-C.
10-liner 2:
#include <stdlib.h>
int main(int argc, char*argv[])
{
while(1)
{
/* do something without screen output */
getenv("TEMP");
}
return 0;
} /* End main() */
here the problem occurs. It is interesting to see that
Dr.Watson shows always the same address, even with completely
differen programs.
Dr. Watson:
0xC0000005 Access Violation
0x0F003084 Address
I can supply a Dr.Watson logfile if it is of any interest.
> If not all programs misbehave like this, it would be interesting
> in particular to know whether the amount of memory used by the
> program is correlated with these problems.
seems to be uncorrelated with memory consumption, as both gcc (actually cc1)
and the 10-liner above shows the same behavior.
> 2) Try compiling the programs with Unixy sbrk algorithm, and see if
> that causes these problems to go away.
> To force a program to use Unixy sbrk, include the following in
> one of the source files and rebuild:
>
> #include <crt0.h>
>
> int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
no significant change.
Tony
**************************************************************
Dipl.-Ing. Anton HELM *T* mailto:tony AT nt DOT tuwien DOT ac DOT at
Institut fuer *U* http://www.nt.tuwien.ac.at/~tony/
Nachrichtentechnik und *W* http://www.nt.tuwien.ac.at/
Hochfrequenztechnik *I* talkto:tony AT eagle DOT nt DOT tuwien DOT ac DOT at
Guszhausstr. 25/389 *E* phoneto:+43-1-58801-3520
A-1040 Wien, AUSTRIA *N* faxto:+43-1-5870583
**************************************************************
finger -l tony AT penguin DOT nt DOT tuwien DOT ac DOT at for PGP public key
**************************************************************
- Raw text -