[M3devel] wrapping postgresql library not enough

Mika Nystrom mika at async.caltech.edu
Thu Apr 21 04:53:04 CEST 2011


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) 




More information about the M3devel mailing list