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

[Marcos Douglas]

On Wed, Mar 21, 2012 at 10:32 AM, Martin <lazarus at mfriebe.de> wrote:
> 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)

Can you send? I'll appreciate that, thanks.

Too my env:
Lazarus 0.9.31 r36175 FPC 2.6.1 i386-win32-win32/win64
FPC: http://svn.freepascal.org/svn/fpc/branches/fixes_2_6
GDB: http://svn.freepascal.org/svn/lazarus/binaries

Which GDB SVN do you think is the best choice?

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

Well, I understood what you said, but I can't read the debug info like
you... I didn't understand anything.  =|

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

Unfortunately, this is a work to GDB developers.  =)

Thanks for all! I learned a lot.

Marcos Douglas