[M3devel] wrapping postgresql library not enough

[Tony Hosking]

Can you dump all the user threads at this point?  ThreadPosix__DumpEverybody() should do it.  We want to see where the other threads might be.

On Apr 20, 2011, at 10:53 PM, Mika Nystrom wrote:

> Hi again,
> 
> So, as I described before, I wrote a program that wraps all of Critical
> Mass's "postgresql" library (PQ.i3) with Scheduler.DisableSwitching /
> Scheduler.EnableSwitching.  Yes, it seems to have reduced the frequency
> at which my application locks up, but it has not eliminated the lockups.
> 
> User threads, AMD64_LINUX.
> 
> I'm not quite sure what to try next.  How can I find out where malloc
> and free might be used reentrantly, assuming that is the problem?
> 
> There may not be any reliable threading in CM3 anymore.  Possibly it's
> reliable on FreeBSD (without -pthread) but I wouldn't bet money on it.
> 
>     Mika
> 
> (gdb) where
> #0  0x00007f7a8da0102e in ?? () from /lib/libc.so.6
> #1  0x00007f7a8d99eb43 in ?? () from /lib/libc.so.6
> #2  0x00007f7a8d99baab in free () from /lib/libc.so.6
> #3  0x000000000077b08d in PQsendQuery ()
> #4  0x0000000000767c12 in PQSchedulerWrap__PQsendQuery (conn=Cannot access memory at address 0x7f7b848a4298
> )
>    at ../AMD64_LINUX/PQSchedulerWrap.m3:210
> #5  0x0000000000763ce0 in UnsafeDatabase__MyExec (t=Cannot access memory at address 0x7f7b848a4328
> ) at ../src/UnsafeDatabase.m3:92
> #6  0x0000000000764a29 in UnsafeDatabase__ExecM (t=Cannot access memory at address 0x7f7b848a43f8
> ) at ../src/UnsafeDatabase.m3:239
> #7  0x0000000000764cee in UnsafeDatabase__TExecM (t=Cannot access memory at address 0x7f7b848a4528
> ) at ../src/UnsafeDatabase.m3:269
> #8  0x0000000000756638 in DesynchronizedDB__TransSExec (trans=Cannot access memory at address 0x7f7b848a45e8
> ) at ../src/DesynchronizedDB.m3:74
> #9  0x00000000005aeac6 in DBTable_gcoms_ordr_statusMonitor__ScanDirty__Attempt.1014 (finalAttempt=Cannot access memory at address 0x7f7b848a463f
> )
>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 => /home/mika/t/calarm/ratsql/src/TableMonitor.mg:41
> #10 0x00000000005ae639 in DBTable_gcoms_ordr_statusMonitor__ScanDirty (cl=Cannot access memory at address 0x7f7b848a4778
> )
>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 => /home/mika/t/calarm/ratsql/src/TableMonitor.mg:73
> #11 0x00000000005b171e in DBTable_gcoms_ordr_statusMonitor__CheckForNew (cl=Cannot access memory at address 0x7f7b848a4958
> )
>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 => /home/mika/t/calarm/ratsql/src/TableMonitor.mg:469
> #12 0x00000000005b1382 in DBTable_gcoms_ordr_statusMonitor__Sync (cl=Cannot access memory at address 0x7f7b848a4ba8
> )
>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 => /home/mika/t/calarm/ratsql/src/TableMonitor.mg:445
> #13 0x00000000005b0e1c in DBTable_gcoms_ordr_statusMonitor__ApplyC (cl=Cannot access memory at address 0x7f7b848a4d58
> )
>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 => /home/mika/t/calarm/ratsql/src/TableMonitor.mg:393
> #14 0x0000000000922eb5 in ThreadPosix__RunThread () at ../src/thread/POSIX/ThreadPosix.m3:1174
> #15 0x00007f7a8d9697b0 in ?? () from /lib/libc.so.6
> #16 0x0000000000000000 in ?? ()
> (gdb)