[M3devel] malloc/free from Modula-3?
Mika Nystrom
mika at async.caltech.edu
Wed Apr 20 08:12:17 CEST 2011
Jay K writes:
>--_e3b69b7a-6d95-4c2e-bef8-027b0afc16b6_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>Can you by chance see the other threads? I suspect not -- user threads I pr=
>esume.
>Can you try sprinking a lot more Disable/EnableSwitching around?
>I guess you tried that..and..?
So far so good. I'll let you know tomorrow. (The application runs
8 1/2 hours a day and has been crashing about twice a day.) The annoying
thing is that when it does lock up, it locks up in one of the wrapped
free()s, not in the unwrapped one.
Mika
>
> - Jay
>
>
>> From: hosking at cs.purdue.edu
>> Date: Fri=2C 15 Apr 2011 11:26:15 -0400
>> To: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] malloc/free from Modula-3?
>>=20
>> I suspect the problem is re-entrance to the library. Should you be disabl=
>ing user thread switching somewhere?
>>=20
>> Antony Hosking | Associate Professor | Computer Science | Purdue Universi=
>ty
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>=20
>>=20
>>=20
>>=20
>> On Apr 15=2C 2011=2C at 6:37 AM=2C Mika Nystrom wrote:
>>=20
>> > Hi m3devel=2C
>> >=20
>> > I'm debugging a problem with some code I have that calls out to C
>> > code. It's calling pqlib (PostgreSQL library) and you might expect
>> > things to go wrong there=2C but as it turns out it's dying in CM3's cod=
>e.
>> >=20
>> > The system is AMD64_LINUX (user threading because of the problems with
>> > pthreads) and the program is just freezing up hard. No segfault=2C
>> > bus error or anything. It locks up a couple of times a day.
>> >=20
>> > What are the rules on calling malloc/free from Modula-3?
>> >=20
>> > Stack trace:
>> >=20
>> > (gdb) where
>> > #0 0x00002ac519a9202e in ?? () from /lib/libc.so.6
>> > #1 0x00002ac519a2fb43 in ?? () from /lib/libc.so.6
>> > #2 0x00002ac519a2caab in free () from /lib/libc.so.6
>> > #3 0x000000000091462f in Cstdlib__free (a=3DCannot access memory at ad=
>dress 0x2ac73b0ef0d8
>> > ) at ../src/C/Common/CstdlibC.c:26
>> > #4 0x000000000091477d in M3toC__FreeCopiedS (s=3DCannot access memory =
>at address 0x2ac73b0ef0f8
>> > ) at ../src/C/Common/M3toC.m3:46
>> > #5 0x00000000007884f0 in UnsafeDatabase_M3_LINE_230.1181 (L_2=3DCannot=
> access memory at address 0x2ac73b0ef118
>> > ) at ../src/UnsafeDatabase.m3:230
>> > #6 0x000000000078881f in UnsafeDatabase__ExecM (t=3DCannot access memo=
>ry at address 0x2ac73b0ef148
>> > ) at ../src/UnsafeDatabase.m3:228
>> > #7 0x0000000000788aa6 in UnsafeDatabase__TExecM (t=3DCannot access mem=
>ory at address 0x2ac73b0ef268
>> > ) at ../src/UnsafeDatabase.m3:258
>> > #8 0x000000000077ad5b in DesynchronizedDB__SExec (t=3DCannot access me=
>mory at address 0x2ac73b0ef328
>> > ) at ../src/DesynchronizedDB.m3:126
>> > #9 0x000000000077c190 in DesynchronizedDB__SMExec (t=3DCannot access m=
>emory at address 0x2ac73b0ef3e8
>> > ) at ../src/DesynchronizedDB.m3:293
>> > #10 0x0000000000569367 in GCOMSOrderManager__OrderEntered (t=3DCannot a=
>ccess memory at address 0x2ac73b0ef5a8
>> > ) at ../src/GCOMSOrderManager.m3:596
>> > #11 0x0000000000566b95 in GCOMSOrderManager__PlaceSingleOrder (t=3DCann=
>ot access memory at address 0x2ac73b0ef668
>> > ) at ../src/GCOMSOrderManager.m3:310
>> > #12 0x000000000041ba25 in EuroDriver__OApply__PlaceOrder.1253 (price=3D=
>{<No data fields>}=2C count=3DCannot access memory at address 0x2ac73b0ef7b=
>8
>> > ) at ../src/EuroDriver.m3:1108
>> > #13 0x000000000041d97c in EuroDriver__OApply__MainLoop.1289 () at ../sr=
>c/EuroDriver.m3:1401
>> > #14 0x00000000004197a1 in EuroDriver__OApply (cl=3DCannot access memory=
> at address 0x2ac73b0efd38
>> > ) at ../src/EuroDriver.m3:1545
>> > #15 0x00000000009112c1 in ThreadPosix__RunThread () at ../src/thread/PO=
>SIX/ThreadPosix.m3:1174
>> > #16 0x00002ac5199fa7b0 in ?? () from /lib/libc.so.6
>> > #17 0x0000000000000000 in ?? ()
>> > (gdb)=20
>> >=20
>> > Here is the code that causes the problem:
>> >=20
>> > VAR
>> > s :=3D CopyTtoS(query)=3B
>> > BEGIN
>> > TRY
>> > t.res :=3D t.myExec(s=2CbusyWait)
>> > FINALLY
>> > FreeCopiedS(s) (* stuck here *)
>> > END
>> > END=3B
>> >=20
>> > The query is a SQL query---t.myExec eventually calls the libpq SQL exec
>> > routine (PQexec I think it's called).
>> >=20
>> > Since this is already an unsafe module I suppose I could just make an
>> > array of CHARs on the stack and pass a pointer to that...
>> >=20
>> >=20
>> > Regards=2C
>> > Mika
>>=20
> =
>
>--_e3b69b7a-6d95-4c2e-bef8-027b0afc16b6_
>Content-Type: text/html; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
><html>
><head>
><style><!--
>.hmmessage P
>{
>margin:0px=3B
>padding:0px
>}
>body.hmmessage
>{
>font-size: 10pt=3B
>font-family:Tahoma
>}
>--></style>
></head>
><body class=3D'hmmessage'>
>Can you by chance see the other threads? I suspect not -- user threads I pr=
>esume.<br>Can you try sprinking a lot more Disable/EnableSwitching around?<=
>br>I guess you tried that..and..?<br><br> =3B- Jay<br><br><br>>=3B Fr=
>om: hosking at cs.purdue.edu<br>>=3B Date: Fri=2C 15 Apr 2011 11:26:15 -0400=
><br>>=3B To: mika at async.caltech.edu<br>>=3B CC: m3devel at elegosoft.com<b=
>r>>=3B Subject: Re: [M3devel] malloc/free from Modula-3?<br>>=3B <br>&g=
>t=3B I suspect the problem is re-entrance to the library. Should you be dis=
>abling user thread switching somewhere?<br>>=3B <br>>=3B Antony Hosking=
> | Associate Professor | Computer Science | Purdue University<br>>=3B 305=
> N. University Street | West Lafayette | IN 47907 | USA<br>>=3B Office +1=
> 765 494 6001 | Mobile +1 765 427 5484<br>>=3B <br>>=3B <br>>=3B <br>=
>>=3B <br>>=3B On Apr 15=2C 2011=2C at 6:37 AM=2C Mika Nystrom wrote:<br=
>>>=3B <br>>=3B >=3B Hi m3devel=2C<br>>=3B >=3B <br>>=3B >=3B =
>I'm debugging a problem with some code I have that calls out to C<br>>=3B=
> >=3B code. It's calling pqlib (PostgreSQL library) and you might expect=
><br>>=3B >=3B things to go wrong there=2C but as it turns out it's dyin=
>g in CM3's code.<br>>=3B >=3B <br>>=3B >=3B The system is AMD64_LIN=
>UX (user threading because of the problems with<br>>=3B >=3B pthreads) =
>and the program is just freezing up hard. No segfault=2C<br>>=3B >=3B =
>bus error or anything. It locks up a couple of times a day.<br>>=3B >=
>=3B <br>>=3B >=3B What are the rules on calling malloc/free from Modula=
>-3?<br>>=3B >=3B <br>>=3B >=3B Stack trace:<br>>=3B >=3B <br>&g=
>t=3B >=3B (gdb) where<br>>=3B >=3B #0 0x00002ac519a9202e in ?? () fr=
>om /lib/libc.so.6<br>>=3B >=3B #1 0x00002ac519a2fb43 in ?? () from /li=
>b/libc.so.6<br>>=3B >=3B #2 0x00002ac519a2caab in free () from /lib/li=
>bc.so.6<br>>=3B >=3B #3 0x000000000091462f in Cstdlib__free (a=3DCanno=
>t access memory at address 0x2ac73b0ef0d8<br>>=3B >=3B ) at ../src/C/Co=
>mmon/CstdlibC.c:26<br>>=3B >=3B #4 0x000000000091477d in M3toC__FreeCo=
>piedS (s=3DCannot access memory at address 0x2ac73b0ef0f8<br>>=3B >=3B =
>) at ../src/C/Common/M3toC.m3:46<br>>=3B >=3B #5 0x00000000007884f0 in=
> UnsafeDatabase_M3_LINE_230.1181 (L_2=3DCannot access memory at address 0x2=
>ac73b0ef118<br>>=3B >=3B ) at ../src/UnsafeDatabase.m3:230<br>>=3B &g=
>t=3B #6 0x000000000078881f in UnsafeDatabase__ExecM (t=3DCannot access mem=
>ory at address 0x2ac73b0ef148<br>>=3B >=3B ) at ../src/UnsafeDatabase.m=
>3:228<br>>=3B >=3B #7 0x0000000000788aa6 in UnsafeDatabase__TExecM (t=
>=3DCannot access memory at address 0x2ac73b0ef268<br>>=3B >=3B ) at ../=
>src/UnsafeDatabase.m3:258<br>>=3B >=3B #8 0x000000000077ad5b in Desync=
>hronizedDB__SExec (t=3DCannot access memory at address 0x2ac73b0ef328<br>&g=
>t=3B >=3B ) at ../src/DesynchronizedDB.m3:126<br>>=3B >=3B #9 0x0000=
>00000077c190 in DesynchronizedDB__SMExec (t=3DCannot access memory at addre=
>ss 0x2ac73b0ef3e8<br>>=3B >=3B ) at ../src/DesynchronizedDB.m3:293<br>&=
>gt=3B >=3B #10 0x0000000000569367 in GCOMSOrderManager__OrderEntered (t=
>=3DCannot access memory at address 0x2ac73b0ef5a8<br>>=3B >=3B ) at ../=
>src/GCOMSOrderManager.m3:596<br>>=3B >=3B #11 0x0000000000566b95 in GCO=
>MSOrderManager__PlaceSingleOrder (t=3DCannot access memory at address 0x2ac=
>73b0ef668<br>>=3B >=3B ) at ../src/GCOMSOrderManager.m3:310<br>>=3B &=
>gt=3B #12 0x000000000041ba25 in EuroDriver__OApply__PlaceOrder.1253 (price=
>=3D{<=3BNo data fields>=3B}=2C count=3DCannot access memory at address =
>0x2ac73b0ef7b8<br>>=3B >=3B ) at ../src/EuroDriver.m3:1108<br>>=3B &g=
>t=3B #13 0x000000000041d97c in EuroDriver__OApply__MainLoop.1289 () at ../s=
>rc/EuroDriver.m3:1401<br>>=3B >=3B #14 0x00000000004197a1 in EuroDriver=
>__OApply (cl=3DCannot access memory at address 0x2ac73b0efd38<br>>=3B >=
>=3B ) at ../src/EuroDriver.m3:1545<br>>=3B >=3B #15 0x00000000009112c1 =
>in ThreadPosix__RunThread () at ../src/thread/POSIX/ThreadPosix.m3:1174<br>=
>>=3B >=3B #16 0x00002ac5199fa7b0 in ?? () from /lib/libc.so.6<br>>=3B=
> >=3B #17 0x0000000000000000 in ?? ()<br>>=3B >=3B (gdb) <br>>=3B &=
>gt=3B <br>>=3B >=3B Here is the code that causes the problem:<br>>=3B=
> >=3B <br>>=3B >=3B VAR<br>>=3B >=3B s :=3D CopyTtoS(quer=
>y)=3B<br>>=3B >=3B BEGIN<br>>=3B >=3B TRY<br>>=3B >=3B =
> t.res :=3D t.myExec(s=2CbusyWait)<br>>=3B >=3B FINALLY<br>&=
>gt=3B >=3B FreeCopiedS(s) (* stuck here *)<br>>=3B >=3B E=
>ND<br>>=3B >=3B END=3B<br>>=3B >=3B <br>>=3B >=3B The query =
>is a SQL query---t.myExec eventually calls the libpq SQL exec<br>>=3B >=
>=3B routine (PQexec I think it's called).<br>>=3B >=3B <br>>=3B >=
>=3B Since this is already an unsafe module I suppose I could just make an<b=
>r>>=3B >=3B array of CHARs on the stack and pass a pointer to that...<b=
>r>>=3B >=3B <br>>=3B >=3B <br>>=3B >=3B Regards=2C<br>>=3B =
>>=3B Mika<br>>=3B <br> </body>
></html>=
>
>--_e3b69b7a-6d95-4c2e-bef8-027b0afc16b6_--
More information about the M3devel
mailing list