Date: Sun, 19 May 2002 21:02:14 +0100
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: The Bat! (v1.60h) UNREG / CD5BF9353B3B7091
X-Priority: 3 (Normal)
Message-ID: <0274202221.20020519210214@softhome.net>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC: sandmann AT clio DOT rice DOT edu, djgpp-workers AT delorie DOT com
Subject: Re: emacs under w2k
In-Reply-To: <Pine.SUN.3.91.1020519161826.18913A-100000@is>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020519161826 DOT 18913A-100000 AT is>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 May 2002 19:01:36.0623 (UTC) FILETIME=[999137F0:01C1FF67]
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



> So what does it tell us about the other type of crash, where you also set 
> the breakpoint like above?  Do we have any reason to believe the 
> breakpoint worked, and the fact it was never hit is indeed an evidence 
> that the crash happens inside the lcall'ed 16-bit helper code?  Because 
> if setting the breakpoint doesn't work, the crash could be anywhere after 
> lcall as well.

> I guess if you try to set breakpoints by address in other places, and 
> those breakpoints do trigger, then we could trust the results of your 
> other session.

I think the results from the other session are OK. I can set working
breakpoints anywhere in brk_common, and they trigger as expected
unless I put them after lcall, in which case program aborts.

Of course that does not explain a bit what's up with breakpoints in
dos_alloc_ok().

Laurynas