[M3devel] malloc/free from Modula-3?

[Tony Hosking]

I suspect the problem is re-entrance to the library. Should you be disabling user thread switching somewhere?

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484




On Apr 15, 2011, at 6:37 AM, Mika Nystrom wrote:

> Hi m3devel,
> 
> 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, but as it turns out it's dying in CM3's code.
> 
> The system is AMD64_LINUX (user threading because of the problems with
> pthreads) and the program is just freezing up hard.  No segfault,
> bus error or anything.  It locks up a couple of times a day.
> 
> What are the rules on calling malloc/free from Modula-3?
> 
> Stack trace:
> 
> (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=Cannot access memory at address 0x2ac73b0ef0d8
> ) at ../src/C/Common/CstdlibC.c:26
> #4  0x000000000091477d in M3toC__FreeCopiedS (s=Cannot access memory at address 0x2ac73b0ef0f8
> ) at ../src/C/Common/M3toC.m3:46
> #5  0x00000000007884f0 in UnsafeDatabase_M3_LINE_230.1181 (L_2=Cannot access memory at address 0x2ac73b0ef118
> ) at ../src/UnsafeDatabase.m3:230
> #6  0x000000000078881f in UnsafeDatabase__ExecM (t=Cannot access memory at address 0x2ac73b0ef148
> ) at ../src/UnsafeDatabase.m3:228
> #7  0x0000000000788aa6 in UnsafeDatabase__TExecM (t=Cannot access memory at address 0x2ac73b0ef268
> ) at ../src/UnsafeDatabase.m3:258
> #8  0x000000000077ad5b in DesynchronizedDB__SExec (t=Cannot access memory at address 0x2ac73b0ef328
> ) at ../src/DesynchronizedDB.m3:126
> #9  0x000000000077c190 in DesynchronizedDB__SMExec (t=Cannot access memory at address 0x2ac73b0ef3e8
> ) at ../src/DesynchronizedDB.m3:293
> #10 0x0000000000569367 in GCOMSOrderManager__OrderEntered (t=Cannot access memory at address 0x2ac73b0ef5a8
> ) at ../src/GCOMSOrderManager.m3:596
> #11 0x0000000000566b95 in GCOMSOrderManager__PlaceSingleOrder (t=Cannot access memory at address 0x2ac73b0ef668
> ) at ../src/GCOMSOrderManager.m3:310
> #12 0x000000000041ba25 in EuroDriver__OApply__PlaceOrder.1253 (price={<No data fields>}, count=Cannot access memory at address 0x2ac73b0ef7b8
> ) at ../src/EuroDriver.m3:1108
> #13 0x000000000041d97c in EuroDriver__OApply__MainLoop.1289 () at ../src/EuroDriver.m3:1401
> #14 0x00000000004197a1 in EuroDriver__OApply (cl=Cannot access memory at address 0x2ac73b0efd38
> ) at ../src/EuroDriver.m3:1545
> #15 0x00000000009112c1 in ThreadPosix__RunThread () at ../src/thread/POSIX/ThreadPosix.m3:1174
> #16 0x00002ac5199fa7b0 in ?? () from /lib/libc.so.6
> #17 0x0000000000000000 in ?? ()
> (gdb) 
> 
> Here is the code that causes the problem:
> 
>    VAR
>      s := CopyTtoS(query);
>    BEGIN
>      TRY
>        t.res := t.myExec(s,busyWait)
>      FINALLY
>        FreeCopiedS(s) (* stuck here *)
>      END
>    END;
> 
> The query is a SQL query---t.myExec eventually calls the libpq SQL exec
> routine (PQexec I think it's called).
> 
> 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...
> 
> 
>   Regards,
>     Mika