Date: Wed, 22 Jul 1998 19:29:52 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Anton Helm <tony AT nt DOT tuwien DOT ac DOT at>
cc: djgpp AT delorie DOT com
Subject: Re: djgpp and WinNT 4.0 summary of problems
In-Reply-To: <3.0.5.32.19980722153436.0099e970@hal.nt.tuwien.ac.at>
Message-ID: <Pine.SUN.3.91.980722192340.12867B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Wed, 22 Jul 1998, Anton Helm wrote:

> I've been using djgpp v2.01 with WinNT 4.0 for a while
> and found some mysterious problems.

Please tell what are the build and the type (workstation or server) of 
this machine.

>    The probability for normal djgpp behavior is about 10%.
>    In 90% of the Ctrl-C hits WinNT catches a protection error,
>    kills the DOS-Window and produces a Dr.Watson message.
>    I haven't yet found out what causes the 10% of normal behavior.
>    (Same behavior with your SIGQUIT test code, Eli.)

The part about the similar behavior with SIGQUIT is expectes, since both 
SIGINT and SIGQUIT are processed by almost identical code.

> 2) * runtime error in djgpp compiled programs (e.g. NULL pointer
>    dereference)
> 
>    The program stops, prints the message "Abort!" in the next line
>    and returns to the DOS prompt. No stack traceback etc., just "Abort!".

This means that somebody called the `abort' library function (it is it 
which prints "Abort!" in v2.01).  Please set a breakpoint in `abort' and 
see if you can get a traceback from the debugger.  I'm curious to know 
how the heck did `abort' get called.

>    (probably a "feature" of the WinNT DPMI service?)

Do they know how to call an arbitrary function in the application?  I 
doubt that.

> 3) * running gdb
>    * debugged program has the above runtime error
>    * run program
>    
>    Again "Abort!" is printed, and the gdb message is
>    "Program exited normally" (!!!)

Again, since `abort' is called, which just exits after printing the 
message, GDB is right here.

>    gdb exits to DOS prompt (NOT to NC) and the working directory changes
>    to the one before invoking NC.

This means that NC is aborted as well.  I don't know why.

> BTW: gdb reads source files from the directories given with the 'dir'
> command (defaults to compile-dir and cwd). Do djgpp executables
> contain the compile-dir info? gdb never finds the sources for
> programs without explicit 'dir' command.

I don't think COFF supports the directory info.

I will try to think about the other problems.  Please see if you can find 
out who calls `abort'.