<pre><tt><tt>Hello:<br>Finally I get mentor debugged with the below commands to avoid hit<br>'return' to continu the execution after Signals, (although the execution <br>still needs several hits on return, you can do several <br>previously and It helps to give continuity to the execution): <br>handle all nostop<br>handle EXC_SOFTWARE stop<br>handle EXC_BREAKPOINT stop<br> <br>Here it is the out of m3gdb session of mentor (running PQueue session<br>Algorithm HeapSort, with Modula-3 Code View and Tree View):<br><br>Program received signal SIG64, Real-time event 64.<br><br>Program received signal SIGXCPU, CPU time limit exceeded.<br><br>Program received signal SIG64, Real-time event 64.<br>[Switching to Thread -1456178256 (LWP 23051)]<br><br>Breakpoint 1, InnerUnlockMutex (m=16_ac9568b4, self=16_ac92c004) at ThreadPThread.m3:168<br>warning: Source file is more recent than executable.<br>168 Die(ThisLine(), "attempt to release an unlocked mutex");<br>(m3gdb)
where<br>#0 InnerUnlockMutex (m=16_ac9568b4, self=16_ac92c004) at ThreadPThread.m3:168<br>#1 0xb7113f69 in UnlockMutex (m=16_ac9568b4) at ThreadPThread.m3:189<br>#2 0xb7b27ff9 in SyncDefault (v=16_ac9568b4, ch=16_ac959268, wait=TRUE) at VBTClass.m3:799<br>#3 0xb7b21d9f in Sync (v=16_ac959268, wait=TRUE) at VBT.m3:1167<br>#4 0xb7b64371 in Sync (v=16_ac956744, ch=16_ac956820, wait=TRUE) at JoinedVBT.m3:101<br>#5 0xb7b27fd6 in SyncDefault (v=16_ac956820, ch=16_ac9567a4, wait=TRUE) at VBTClass.m3:797<br>#6 0xb7b27fd6 in SyncDefault (v=16_ac9567a4, ch=16_ac955ea4, wait=TRUE) at VBTClass.m3:797<br>#7 0xb7b27fd6 in SyncDefault (v=16_ac955ea4, ch=16_b2c5fcbc, wait=TRUE) at VBTClass.m3:797<br>#8 0xb7b27fd6 in SyncDefault (v=16_b2c5fcbc, ch=16_b2c5ff28, wait=TRUE) at VBTClass.m3:797<br>#9 0xb7b27fd6 in SyncDefault (v=16_b2c5ff28, ch=16_b2c5fdac, wait=TRUE) at VBTClass.m3:797<br>#10 0xb7b21d9f in Sync (v=16_b2c5fdac, wait=TRUE) at VBT.m3:1167<br>#11 0xb7d525f3 in
MGRedisplay (v=16_b2c5fdac, br=RECORD r = RECORD west = 0; east = 0; north = 0; south = 0; END; p = NIL; END)<br> at MGV.m3:146<br>#12 0xb7d41b90 in DoAnimation (t=16_b2cac1ac, time=0.1202204, timePrev=0.117730595, v=16_b2c5fdac, mg=NIL) at Animate.m3:57<br>#13 0xb7d41ca8 in Do (t=16_b2cac1ac, mg=NIL, v=16_b2c5fdac, duration=1) at Animate.m3:74<br>#14 0xb7d536d1 in Animation (v=16_b2c5fdac, duration=1) at MGV.m3:313<br>#15 0xb7d83fdc in AnimateGraph (graph=16_b2c5fcbc, t0=0, t1=1) at GraphVBT.m3:656<br>#16 0x081534b3 in HeapOpInit (view=16_ac955ea4, k=4) at PQViews.m3:152<br>#17 0x0814c1d8 in OEDispatcher (v=16_ac955ea4, evt=16_b2be4f64) at PQueueIE.m3:97<br>#18 0xb7df19db in ViewThread (self=16_b2c3b808) at Zeus.m3:331<br>#19 0xb7116382 in RunThread (me=16_08307368) at ThreadPThread.m3:548<br>#20 0xb7115f61 in ThreadBase (param=16_08307368) at ThreadPThread.m3:518<br>#21 0xb6eb4341 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0<br>#22 0xb6e484ee in clone
() from /lib/tls/i686/cmov/libc.so.6<br>(m3gdb) <br><br>Any more information useful to send you?<br><br>Thanks, <br>Daniel Benavides<br><br>On Feb 1, 2007, at 3:34 PM, Daniel Alejandro Benavides D. wrote:<br><br>> Hi:<br>><br>> Some things besides what found with mentor:<br>><br>> danielb@sl11:~$ mentor @M3stackdump<br>><br>><br>> ***<br>> *** runtime error:<br>> *** Thread client error: attempt to release an unlocked mutex<br>> *** file "ThreadPThread.m3", line 168<br>> ***<br>><br>> ------------------ EXCEPTION HANDLER STACK ---------------------<br>> 0xa22bab80 LOCK mutex = 0xb241b164<br>> 0xa22babd0 LOCK mutex = 0xb2416c78<br>> 0xa22bac30 LOCK mutex = 0xb2416d54<br>> 0xa22bac80 LOCK mutex = 0xb2416cd8<br>> 0xa22bacd0 LOCK mutex = 0xb2410378<br>> 0xa22bad20 LOCK mutex = 0xb23fa104<br>> 0xa22bad70 LOCK mutex = 0xb23fa370<br>> 0xa22badc0 LOCK mutex = 0xb23fa1f4<br>> 0xa22bae20 LOCK mutex =
0xb23fa288<br>> 0xa22bae58 RAISES {}<br>> 0xa22bb170 TRY-EXCEPT {0x718ac4e9}<br>> 0xa22bb250 TRY-EXCEPT {0x718ac4e9}<br>> ----------------------------------------------------------------<br>> Cancelado<br>> danielb@sl11:~$<br>><br>> I didn't debugged mentor, but I tried another program, cvsup,<br>> and with GUI problems after a seconds the process finishes<br>> but no advise of runtime error, however with no-gui It simply works <br>> well.<br>><br>> Also Im trying the examples of the parallel chapter of the book<br>> "Programming in Modula-3" by Laszlo Boszormenyi & Carsten Weich,<br>> with the NThreads example (which you can download on the url<br>> <a href="http://web.archive.org/web/19970814162826/www.ifi.uni-klu.ac.at/" target="_blank">http://web.archive.org/web/19970814162826/www.ifi.uni-klu.ac.at/</a> <br>> Modula-3/m3book/examples.html )<br>> You will need the m3local library shipped and a m3makefile like
<br>> this below:<br>> import ("m3local")<br>> implementation("NThreads")<br>> program("NThreads")<br>><br>> I get this on the console with the Pthread version:<br>> the program will call Nl new line after a 10 is printed.<br>> 9 10<br>> 4 7 8 1 2 3 5 6 9 10<br>> 4 10<br>> 4 7 9 1 2 3 5 6 5 6 8 9 10<br>> 1 2 3 4 7 3 4 5 6 8 6 8 9 3 4 5 7 10<br>> 1 10<br>> 1 2 3 4 5 6 7 8 9 7 8 9 10<br>> 1 2 1 2 3 7 8 9 10<br>> 4 5 4 5 6 7 8 9 10<br>> 1 2 3 1 2 3 4 5 6 5 6 7 1 2 3 4 8 9 10<br>> 5 6 7 1 2 3 4 3 4 8 1 2 5 6 7 9 10<br>> 3 4 8 4 8 1 3 5 6 7 9 10<br>> 9 10<br>> 2 3 4 5 6 7 8 1 7 8 9 10<br>> 2 10<br>> 2 3 7 8 9 1 4 5 6 10<br>> 2 3 7 8 9 1 9 1 4 7 8 10<br>> 2 3 5 6 9 1 4 1 4 7 9 10<br>> 2 3 5 6 5 6 8 9 10<br>> 1 2 3 4 7 3 4 5 6 8 6 8 9 3 4 5 7 10<br>> 1 10<br>> 1 2 3 4 5 6 7 8 9 7 8 9 10<br>> 1 2 1 2 3 7 8 9 10<br>> 4 5 6 1 2 3 7 8 9 10<br>> 9 10<br>> 4 7 8 1 2 3 5 6 9 10<br>> 4
10<br>> 4 7 9 1 2 3 5 6 5 6 8 9 10<br>> 1 2 3 4 7 3 4 5 6 8 6 8 9 3 4 5 7 10<br>> 1 10<br>> 1 2 3 4 5 6 7 8 9 7 8 9 10<br>> 1 2 1 2 3 7 8 9 10<br>> 4 5 6 1 2 3 7 8 9 10<br>> 9 10<br>><br>> But with the POSIX implementation, this is a extract of the out:<br>> It ends according to the example until Return is pressed.<br>><br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> 9 8 7 6 5 4 3 2 1 10<br>> Certainly, and according to the book, the
first one is more <br>> expectable.<br>> I would like to know your opinions about this issue.<br>> Besides with import("libsio") in place of import ("m3local") on the <br>> m3makefile<br>> you get the numbers in a distribution similar to the above but the <br>> number of digits<br>> in each line is more uniform (ten by line) on the pthread version <br>> this time.<br>><br>> Besides I know the Upthread.i3 interface on<br>> m3-libs/m3core/src/unix/linux-libc6 has a the procedure<br>><br>> PROCEDURE attr_setschedparam (VAR attr: pthread_attr_t;<br>> READONLY param: struct_sched_param): <br>> int;<br>> that could be useful to change the scheduling policy, but certainly<br>> I didn't find with grep in all the cm3 distro where it is used.<br>> The Round Robin policy according to the documentation<br>> of pthreads, is only available on process running with superuser <br>>
privileges.<br>><br>> Thanks,<br>> Daniel Benavides<br>><br>> > Tony Hosking <a href="Compose?To=hosking@cs.purdue.edu&YY=99413&y5beta=yes&y5beta=yes&order=down&sort=date&pos=0&view=a&head=b">hosking@cs.purdue.edu</a> wrote:<br>> ><br>> > A stack trace would be useful. Perhaps you can run again with<br>> > @M3stackdump specified on the command line. Alternatively, if you<br>> > run inside gdb you can show the stack dump at the point of the<br>> > error<br>> > by setting a breakpoint at line 168 in ThreadPThread.m3.<br>> ><br>> > I notice that you are using priority scheduling -- not sure what<br>> > that<br>> > will do to things. Can you try it with round robin scheduling?<br>> ><br>> > On Jan 31, 2007, at 12:05 PM, Daniel Alejandro Benavides D. wrote:<br>> ><br>> > > Hello:<br>> > ><br>> > > I have compiled the cm3 cvs
updated with the Pthread support<br>> > under<br>> > > kubuntu 6.06 Linux. I have done this adding the value "PTHREAD"<br>> > on<br>> > > the array SYSTEM_LIBORDER<br>> > ><br>> > > SYSTEM_LIBORDER = [ "OPENGL", "DECPEX", "MOTIF", "X11", "TCP",<br>> > "ODBC",> "POSTGRES95", "FLEX-BISON", "LEX-<br>> > YACC", "LIBC",<br>> > > "PTHREAD" ]<br>> > ><br>> > > and the variable "PTHREAD" : [ "-L/usr/lib", "-lpthread" ],<br>> > > on the array SYSTEM_LIBS<br>> > ><br>> > > But when running a mentor animation I get this runtime error<br>> > > consistently about a seconds later after began an animation, then<br>> ><br>> > > this is the out:<br>> > ><br>> > > root@sl11:/home/danielb/cm3-5.4-Rc2/cm3/scripts# mentor <br>showthread<br>> > ><br>> > ><br>> > > ***<br>> > > *** runtime error:<br>>
> > *** Thread client error: attempt to release an unlocked mutex<br>> > > *** file "ThreadPThread.m3", line 168<br>> > > ***<br>> > ><br>> > > Cancelado<br>> > > root@sl11:/home/danielb/cm3-5.4-Rc2/cm3/scripts#<br>> > ><br>> > > This system has<br>> > > "POSIX version set to 200112,<br>> > > including support for priority scheduling"<br>> > ><br>> > > Thanks,<br>> > > Daniel Benavides<br>> > ><br>> ></tt></tt></pre><p>
<hr size=1><br><font face="Verdana" size="-2">LLama Gratis a cualquier PC del Mundo.<br>Llamadas a fijos y móviles desde 1 céntimo por minuto.<br><a href="http://us.rd.yahoo.com/mail/es/tagline/messenger/*http://es.voice.yahoo.com/">http://es.voice.yahoo.com</a></font>