[M3devel] wrapping postgresql library not enough

[Mika Nystrom]

Aha, I will try that if it happens again.  I wrapped more things that I think
might be iffy in my program.

But I have a feeling ThreadPosix__DumpEverybody won't work... the
application is probably deadlocked by having a single thread locking
against itself with some sort of pthread lock.  I should look at the
source code of free.

     Mika

Tony Hosking writes:
>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,
>>=20
>> 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.
>>=20
>> User threads, AMD64_LINUX.
>>=20
>> 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?
>>=20
>> 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.
>>=20
>>     Mika
>>=20
>> (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=3DCannot =
>access memory at address 0x7f7b848a4298
>> )
>>    at ../AMD64_LINUX/PQSchedulerWrap.m3:210
>> #5  0x0000000000763ce0 in UnsafeDatabase__MyExec (t=3DCannot access =
>memory at address 0x7f7b848a4328
>> ) at ../src/UnsafeDatabase.m3:92
>> #6  0x0000000000764a29 in UnsafeDatabase__ExecM (t=3DCannot access =
>memory at address 0x7f7b848a43f8
>> ) at ../src/UnsafeDatabase.m3:239
>> #7  0x0000000000764cee in UnsafeDatabase__TExecM (t=3DCannot access =
>memory at address 0x7f7b848a4528
>> ) at ../src/UnsafeDatabase.m3:269
>> #8  0x0000000000756638 in DesynchronizedDB__TransSExec (trans=3DCannot =
>access memory at address 0x7f7b848a45e8
>> ) at ../src/DesynchronizedDB.m3:74
>> #9  0x00000000005aeac6 in =
>DBTable_gcoms_ordr_statusMonitor__ScanDirty__Attempt.1014 =
>(finalAttempt=3DCannot access memory at address 0x7f7b848a463f
>> )
>>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 =3D> =
>/home/mika/t/calarm/ratsql/src/TableMonitor.mg:41
>> #10 0x00000000005ae639 in DBTable_gcoms_ordr_statusMonitor__ScanDirty =
>(cl=3DCannot access memory at address 0x7f7b848a4778
>> )
>>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 =3D> =
>/home/mika/t/calarm/ratsql/src/TableMonitor.mg:73
>> #11 0x00000000005b171e in =
>DBTable_gcoms_ordr_statusMonitor__CheckForNew (cl=3DCannot access memory =
>at address 0x7f7b848a4958
>> )
>>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 =3D> =
>/home/mika/t/calarm/ratsql/src/TableMonitor.mg:469
>> #12 0x00000000005b1382 in DBTable_gcoms_ordr_statusMonitor__Sync =
>(cl=3DCannot access memory at address 0x7f7b848a4ba8
>> )
>>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 =3D> =
>/home/mika/t/calarm/ratsql/src/TableMonitor.mg:445
>> #13 0x00000000005b0e1c in DBTable_gcoms_ordr_statusMonitor__ApplyC =
>(cl=3DCannot access memory at address 0x7f7b848a4d58
>> )
>>    at ../AMD64_LINUX/DBTable_gcoms_ordr_statusMonitor.m3 =3D> =
>/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)=20