[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>&nbsp=3B- Jay<br><br><br>&gt=3B Fr=
>om: hosking at cs.purdue.edu<br>&gt=3B Date: Fri=2C 15 Apr 2011 11:26:15 -0400=
><br>&gt=3B To: mika at async.caltech.edu<br>&gt=3B CC: m3devel at elegosoft.com<b=
>r>&gt=3B Subject: Re: [M3devel] malloc/free from Modula-3?<br>&gt=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>&gt=3B <br>&gt=3B Antony Hosking=
> | Associate Professor | Computer Science | Purdue University<br>&gt=3B 305=
> N. University Street | West Lafayette | IN 47907 | USA<br>&gt=3B Office +1=
> 765 494 6001 | Mobile +1 765 427 5484<br>&gt=3B <br>&gt=3B <br>&gt=3B <br>=
>&gt=3B <br>&gt=3B On Apr 15=2C 2011=2C at 6:37 AM=2C Mika Nystrom wrote:<br=
>>&gt=3B <br>&gt=3B &gt=3B Hi m3devel=2C<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B =
>I'm debugging a problem with some code I have that calls out to C<br>&gt=3B=
> &gt=3B code.  It's calling pqlib (PostgreSQL library) and you might expect=
><br>&gt=3B &gt=3B things to go wrong there=2C but as it turns out it's dyin=
>g in CM3's code.<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B The system is AMD64_LIN=
>UX (user threading because of the problems with<br>&gt=3B &gt=3B pthreads) =
>and the program is just freezing up hard.  No segfault=2C<br>&gt=3B &gt=3B =
>bus error or anything.  It locks up a couple of times a day.<br>&gt=3B &gt=
>=3B <br>&gt=3B &gt=3B What are the rules on calling malloc/free from Modula=
>-3?<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B Stack trace:<br>&gt=3B &gt=3B <br>&g=
>t=3B &gt=3B (gdb) where<br>&gt=3B &gt=3B #0  0x00002ac519a9202e in ?? () fr=
>om /lib/libc.so.6<br>&gt=3B &gt=3B #1  0x00002ac519a2fb43 in ?? () from /li=
>b/libc.so.6<br>&gt=3B &gt=3B #2  0x00002ac519a2caab in free () from /lib/li=
>bc.so.6<br>&gt=3B &gt=3B #3  0x000000000091462f in Cstdlib__free (a=3DCanno=
>t access memory at address 0x2ac73b0ef0d8<br>&gt=3B &gt=3B ) at ../src/C/Co=
>mmon/CstdlibC.c:26<br>&gt=3B &gt=3B #4  0x000000000091477d in M3toC__FreeCo=
>piedS (s=3DCannot access memory at address 0x2ac73b0ef0f8<br>&gt=3B &gt=3B =
>) at ../src/C/Common/M3toC.m3:46<br>&gt=3B &gt=3B #5  0x00000000007884f0 in=
> UnsafeDatabase_M3_LINE_230.1181 (L_2=3DCannot access memory at address 0x2=
>ac73b0ef118<br>&gt=3B &gt=3B ) at ../src/UnsafeDatabase.m3:230<br>&gt=3B &g=
>t=3B #6  0x000000000078881f in UnsafeDatabase__ExecM (t=3DCannot access mem=
>ory at address 0x2ac73b0ef148<br>&gt=3B &gt=3B ) at ../src/UnsafeDatabase.m=
>3:228<br>&gt=3B &gt=3B #7  0x0000000000788aa6 in UnsafeDatabase__TExecM (t=
>=3DCannot access memory at address 0x2ac73b0ef268<br>&gt=3B &gt=3B ) at ../=
>src/UnsafeDatabase.m3:258<br>&gt=3B &gt=3B #8  0x000000000077ad5b in Desync=
>hronizedDB__SExec (t=3DCannot access memory at address 0x2ac73b0ef328<br>&g=
>t=3B &gt=3B ) at ../src/DesynchronizedDB.m3:126<br>&gt=3B &gt=3B #9  0x0000=
>00000077c190 in DesynchronizedDB__SMExec (t=3DCannot access memory at addre=
>ss 0x2ac73b0ef3e8<br>&gt=3B &gt=3B ) at ../src/DesynchronizedDB.m3:293<br>&=
>gt=3B &gt=3B #10 0x0000000000569367 in GCOMSOrderManager__OrderEntered (t=
>=3DCannot access memory at address 0x2ac73b0ef5a8<br>&gt=3B &gt=3B ) at ../=
>src/GCOMSOrderManager.m3:596<br>&gt=3B &gt=3B #11 0x0000000000566b95 in GCO=
>MSOrderManager__PlaceSingleOrder (t=3DCannot access memory at address 0x2ac=
>73b0ef668<br>&gt=3B &gt=3B ) at ../src/GCOMSOrderManager.m3:310<br>&gt=3B &=
>gt=3B #12 0x000000000041ba25 in EuroDriver__OApply__PlaceOrder.1253 (price=
>=3D{&lt=3BNo data fields&gt=3B}=2C count=3DCannot access memory at address =
>0x2ac73b0ef7b8<br>&gt=3B &gt=3B ) at ../src/EuroDriver.m3:1108<br>&gt=3B &g=
>t=3B #13 0x000000000041d97c in EuroDriver__OApply__MainLoop.1289 () at ../s=
>rc/EuroDriver.m3:1401<br>&gt=3B &gt=3B #14 0x00000000004197a1 in EuroDriver=
>__OApply (cl=3DCannot access memory at address 0x2ac73b0efd38<br>&gt=3B &gt=
>=3B ) at ../src/EuroDriver.m3:1545<br>&gt=3B &gt=3B #15 0x00000000009112c1 =
>in ThreadPosix__RunThread () at ../src/thread/POSIX/ThreadPosix.m3:1174<br>=
>&gt=3B &gt=3B #16 0x00002ac5199fa7b0 in ?? () from /lib/libc.so.6<br>&gt=3B=
> &gt=3B #17 0x0000000000000000 in ?? ()<br>&gt=3B &gt=3B (gdb) <br>&gt=3B &=
>gt=3B <br>&gt=3B &gt=3B Here is the code that causes the problem:<br>&gt=3B=
> &gt=3B <br>&gt=3B &gt=3B    VAR<br>&gt=3B &gt=3B      s :=3D CopyTtoS(quer=
>y)=3B<br>&gt=3B &gt=3B    BEGIN<br>&gt=3B &gt=3B      TRY<br>&gt=3B &gt=3B =
>       t.res :=3D t.myExec(s=2CbusyWait)<br>&gt=3B &gt=3B      FINALLY<br>&=
>gt=3B &gt=3B        FreeCopiedS(s) (* stuck here *)<br>&gt=3B &gt=3B      E=
>ND<br>&gt=3B &gt=3B    END=3B<br>&gt=3B &gt=3B <br>&gt=3B &gt=3B The query =
>is a SQL query---t.myExec eventually calls the libpq SQL exec<br>&gt=3B &gt=
>=3B routine (PQexec I think it's called).<br>&gt=3B &gt=3B <br>&gt=3B &gt=
>=3B Since this is already an unsafe module I suppose I could just make an<b=
>r>&gt=3B &gt=3B array of CHARs on the stack and pass a pointer to that...<b=
>r>&gt=3B &gt=3B <br>&gt=3B &gt=3B <br>&gt=3B &gt=3B   Regards=2C<br>&gt=3B =
>&gt=3B     Mika<br>&gt=3B <br> 		 	   		  </body>
></html>=
>
>--_e3b69b7a-6d95-4c2e-bef8-027b0afc16b6_--



More information about the M3devel mailing list