[fpc-pascal] SQLdb: problem using GDB, but do not have memleak

[Martin]

On 21/03/2012 12:49, Marcos Douglas wrote:
> On Tue, Mar 20, 2012 at 6:27 PM, Martin<lazarus at mfriebe.de>  wrote:
>> On 20/03/2012 12:08, Marcos Douglas wrote:
>>> Hi,
>>>
>>> I was testing the new connector to MSSQL when I found a problem.
>>> If I compile and run in console, I have no memleak. Good. But if I put
>>> a breakpoint in AConnection.Free; and press F8, I got this:
>>>
>>> ERROR
>>> ,msg="Warning:\nCannot insert breakpoint -237.\nError accessing memory
>>> address 0x7816cd30: Input/output error.\n"
>>>
>> Does the issue happen the first time you press F8, or to you have to press a
>> 2nd time?
> When I press a first time... but I think some times in a 2nd time.  =|
>
>> In other words: Is it possble the debugger pauses inside free (possible in a
>> dll) and that when you hit F8 then, it can not step, because the dll has no
>> debug info?
> Yes, I think is possible...
>
>> If in stopped in the DLL, it might still put the green arrow on your source
>> =>  first stack with frame debug info...
>>
>> Open and watch the stack window.
>>
>> ---
>> Also open the "debug output" window. Open this one before you start your
>> app. Then copy the content.
> The content was copied below.
>
>> ---
>> If indeed gdb stops inside a dll, then F8 simply can not work

Ok, I looked through it. Nott much of a result. Except there is no way 
to fix it, other to get the GDB developers to fix it in GDB.

Though you might want to try gdb 7.0.50 from mingw. It seems that 7.3 
and 7.4 have some sort of regression in thread handling (on a different 
and rather rare issue) (Not sure where 7.1 stands).
Or go for 7.4 (I can send it to you with the required libs)

So what happens seems:

*  The first F8
- seems to execute (next stop is 2 lines below)
- but throws a warning:
   ~"warning: Error removing breakpoint -108\n"

In this step several libraries are unloaded. It appears that for an 
unknown reason (and something beyond my knowledge) GDB did set a 
temporary break in one of that dll

At that time there is also a 2nd thread involved (Lots of dll on window 
start threads).

{id="2",target-id="Thread 4220.0x155c",
   
frame={level="0",addr="0x7c90e514",func="ntdll!LdrAccessResource",args=[],from="C:\\WINDOWS\\system32\\ntdll.dll"},state="stopped"},
{id="1",target-id="Thread 4220.0xe88",
   
frame={level="0",addr="0x00401c34",func="main",args=[],file="dbtest.pas",fullname="w:\\.....\\dbtest.pas",line="119"},state="stopped"}]

I do not know where that temp breakpoint was meant to go, or which thread.


* Then the next F8 fails

<-exec-next>
^error,msg="Warning:\nCannot insert breakpoint -110.\nError accessing
memory address 0x7816cd30: Input/output error.\n"
(gdb)

That address must be in some library. Most likely in one of those that 
were unloaded

Your main thread is in your code, not in a library.

------------------------------

- I do not know why GDB expects a possible end of the single step in a 
library
- I do not know why gdb (at least if I guess correct) tries to set a 
break in an unloaded lib.