Hello all, I have a patch that has started to cause a crash in PD. In trying to figure out exactly what is happening, I reworked the patch, and now each of the smaller chunks of code are in their own subpatch. So, now the patch doesn't ALWAYS crash. Now the only time it crashes is when I open the subpatch containing the offending code, BUT only after that code has been executed at least once.
Lets see if I can give an outline...
1. Open the patch. 2. Setup the patch for operation. 3. Call the subpatch that appears to be cause trouble. Everything executes properly and does what it is supposed to do. 4. Open the subpatch that contains the troublesome code, and PD crashes before it can display the patch.
I have checked this in several different versions of PD, from the nightly builds (ranging from 1129 back to 0927), as well as the 39 extended version. And all of them crash in the same way.
This is the first time I have run into something like this, and I am not sure how to proceed in troubleshooting this problem. I looked at the stack traces in the logs, and everything appears to be PD code that is executing.
Thread 0 Crashed: 0 pd 0x0003cbb0 obj_noutlets + 16 (m_obj.c:549) 1 pd 0x0000ca0c glist_drawiofor + 76 (g_text.c:1188) 2 pd 0x0000d030 text_drawborder + 976 (g_text.c:1314) 3 pd 0x0000d3ac text_vis + 156 (g_text.c:1061) 4 pd 0x0001eca0 gobj_vis + 352 (g_editor.c:91) 5 pd 0x00003eb0 canvas_map + 128 (g_canvas.c:647) 6 pd 0x0003b0d4 pd_typedmess + 1092 (m_class.c:771) 7 pd 0x0003b23c pd_typedmess + 1452 (m_class.c:792) 8 pd 0x0003f020 binbuf_eval + 1104 (m_binbuf.c:673) 9 pd 0x00045c70 socketreceiver_read + 640 (s_inter.c:542) 10 pd 0x000444dc sys_domicrosleep + 316 (s_inter.c:182) 11 pd 0x00042850 m_scheduler + 1248 (m_sched.c:490) 12 pd 0x00044240 sys_main + 1440 (s_main.c:311) 13 pd 0x00002174 _start + 340 (crt.c:272) 14 pd 0x0000201c start + 60
I am running on a Mac OS X 10.4.11, while not all of the crashes give the exact same stack trace, this is the most prevalent one.
Thanks,
Mike
Mike McGonagle wrote:
Hello all,
I have a patch that has started to cause a crash in PD. In trying to figure out exactly what is happening, I reworked the patch, and now each of the smaller chunks of code are in their own subpatch. So, now the patch doesn't ALWAYS crash. Now the only time it crashes is when I open the subpatch containing the offending code, BUT only after that code has been executed at least once.
Lets see if I can give an outline...
- Open the patch.
- Setup the patch for operation.
- Call the subpatch that appears to be cause trouble. Everything
executes properly and does what it is supposed to do. 4. Open the subpatch that contains the troublesome code, and PD crashes before it can display the patch.
Thread 0 Crashed: 0 pd 0x0003cbb0 obj_noutlets + 16 (m_obj.c:549) 1 pd 0x0000ca0c glist_drawiofor + 76
so pd is crashing when it tries to draw an object (most likely: a certain object)
since it is unlikely that a "normal object" (no gui, no gop) will cause the crash (though not impossible; i only assume so, because if it was the case, we would get this bug report more often), so it would be interesting to know which graphical objects are hidden in your subpatch.
apart from that, like always: sharing code could help...
mfgasd.r IOhannes
On Dec 5, 2007 3:34 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
so pd is crashing when it tries to draw an object (most likely: a certain object)
since it is unlikely that a "normal object" (no gui, no gop) will cause the crash (though not impossible; i only assume so, because if it was the case, we would get this bug report more often), so it would be interesting to know which graphical objects are hidden in your subpatch.
apart from that, like always: sharing code could help...
But that is what is strange about this, I am not using any graphical objects in the subpatch. And the other weirdness is that the first version of the program I wrote, it crashed on the very same leg of code
[t b b] | | | Crashes all the time. | Doesn't crash
And when I switchted the two legs, the one that was crashing originally still keeps crashing.
And as far as the "sharing of the code", I only hesitate because it involves one of my externals, and it always seems others are hesitant to compile these things just to test something. I could be wrong...
That being said, I am going to post the latest version, and then the offending code. (The other part is that I am also using some stuff in a library that I am developing, so that also needs to be added to the path...)
Mike
mfgasd.r IOhannes
Ok, I have posted the latest version of the SQLite external to http://puredata.info/Members/mjmogo It will be the second one on the list. It is version 0.13 just so you know.
I also attached the library stuff that I have been working on. Once you get that stuff up (and you did ask for code...), you can load up the patch under the testing folder in Orbit2. Once you do that, you will need to open up the attractors4.db file. Select the popup to the left, and choose 'all'. From here, select 'latoocarfian' for the attractor (the popup just to the right). Once you have done that, select the popup underneath, and choose one of the instances (i1, i2, etc).
This is where you will try to open the Attractor-GUI abstraction, and then the [pd load-attractor-instance] subpatch. This should open without any troubles. When you open up this window, you will notice the connection between the 'sql' message box going into the [sqlite] external has been disconnected. This branch is NOT the offending branch. The one that is causing troubles is on the other branch of the first [t b b] at the top.
Any help in pointing to what I could do to troubleshoot this would be earth-shattering in learning more about PD. And thanks for your help so far.
Mike
(PS, anyone who compiles this on any other platform other than Mac OS X, if you could forward the makefile you used, I can incorporate it into the main makefile.)
I forgot to tell you want to do to make it crash... Once you are done looking at that subpatch. Close it... Go back to the main window, and hit the button connected to the [send mine-attractor-load-instance]. This should print out a series of four values to the console. Select another from the instance popup (i1, i2, etc.), and hit this again. It should work just fine, no matter how many times you do this.
Now go back and open the [pd load-attractor-instance] subpatch in the Attractor-GUI abstraction. Does it crash?
There you have it, two downloads, one shitty install, and a crashing program...
But hey, thanks.
Mike
On Dec 5, 2007 2:47 PM, Mike McGonagle mjmogo@gmail.com wrote:
Ok, I have posted the latest version of the SQLite external to http://puredata.info/Members/mjmogo It will be the second one on the list. It is version 0.13 just so you know.
I also attached the library stuff that I have been working on. Once you get that stuff up (and you did ask for code...), you can load up the patch under the testing folder in Orbit2. Once you do that, you will need to open up the attractors4.db file. Select the popup to the left, and choose 'all'. From here, select 'latoocarfian' for the attractor (the popup just to the right). Once you have done that, select the popup underneath, and choose one of the instances (i1, i2, etc).
This is where you will try to open the Attractor-GUI abstraction, and then the [pd load-attractor-instance] subpatch. This should open without any troubles. When you open up this window, you will notice the connection between the 'sql' message box going into the [sqlite] external has been disconnected. This branch is NOT the offending branch. The one that is causing troubles is on the other branch of the first [t b b] at the top.
Any help in pointing to what I could do to troubleshoot this would be earth-shattering in learning more about PD. And thanks for your help so far.
Mike
(PS, anyone who compiles this on any other platform other than Mac OS X, if you could forward the makefile you used, I can incorporate it into the main makefile.)
-
IOhannes m zmoelnig -
Mike McGonagle