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

> 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

- Raw text -