Date:	Thu, 5 Aug 1999 10:17:48 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Radu Georgescu aka skoola <skoola AT go DOT ro>
cc:	djgpp AT delorie DOT com
Subject:	Re: dpmi lock
In-Reply-To:	<35A93079.C30A2DC2@go.ro>
Message-ID:	<Pine.SUN.3.91.990805101731.14908K-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 13 Jul 1998, Radu Georgescu aka skoola wrote:

> shouldn't _go32_dpmi_lock_data(...) lock the data so no other function
> may modify it until it is unlocked (and generate some protection fault
> error)?

No, locking data is not about protection, it's about virtual memory.
You lock a memory region to make sure it will never be paged out of
physical memory by the virtual memory mechanism.  But locking memory
doesn't change anything in the access rights to that memory.

> i tried to use this in order to find the function that overwrites some
> data and this didn't work. any other ideas (except for parsing the whole
> code because it is too big and the error appairs only sometimes).
> thanks!!

Run the program under a debugger and put a data-write breakpoint
(a.k.a. watchpoint) at the address that gets overwritten.  Then
whenever the overwrite happens, the debugger will kick in and show you
the offending code line.

- Raw text -