Message-Id: <3.0.5.32.19980723110813.009728e0@hal.nt.tuwien.ac.at>
Date: Thu, 23 Jul 1998 11:08:13 +0200
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Anton Helm <tony AT nt DOT tuwien DOT ac DOT at>
Subject: Re: djgpp and WinNT 4.0 summary of problems
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.980723094441.14884C-100000@is>
References: <3 DOT 0 DOT 5 DOT 32 DOT 19980722192339 DOT 0099e970 AT hal DOT nt DOT tuwien DOT ac DOT at>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

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
**************************************************************