Aack!!! Can't save!

Feb 22, 2007 at 8:00am

Aack!!! Can't save!

Everytime I try to save my patch Max quits.

Here’s the (hopefully) relevant crash report info:

Thread 0 Crashed:
0 com.cycling74.MaxMSP46 0x0000ecb0 binbuf_insert + 160 (binbuf.c:624)
1 com.cycling74.MaxMSP46 0x0000cfdc atombuf_savebox + 572 (atombuf.c:568)
2 com.cycling74.MaxMSP46 0x00106d58 vmessage_psave(_vmessage*, void*) + 244 (vmessage.c:299)
3 com.cycling74.MaxMSP46 0x00017d18 box_save + 84 (box.c:1146)
4 com.cycling74.MaxMSP46 0x0004cda4 patcher_save + 612 (patcher.c:1305)
5 com.cycling74.MaxMSP46 0x00108fd8 vnewobj_psave(vnewobj*, void*) + 352 (vnewobj.c:325)
6 com.cycling74.MaxMSP46 0x00017d18 box_save + 84 (box.c:1146)
7 com.cycling74.MaxMSP46 0x0004cda4 patcher_save + 612 (patcher.c:1305)
8 com.cycling74.MaxMSP46 0x00108fd8 vnewobj_psave(vnewobj*, void*) + 352 (vnewobj.c:325)
9 com.cycling74.MaxMSP46 0x00017d18 box_save + 84 (box.c:1146)
10 com.cycling74.MaxMSP46 0x0004cda4 patcher_save + 612 (patcher.c:1305)
11 com.cycling74.MaxMSP46 0x00057d1c patcher_saveto + 124 (patchermenu.c:587)
12 com.cycling74.MaxMSP46 0x0009c670 wind_save + 192 (window.c:1780)
13 com.cycling74.MaxMSP46 0x000a0b50 wind_filemenu + 236 (window.c:1300)
14 com.cycling74.MaxMSP46 0x00041b48 menu_dobar + 732 (menu.c:793)
15 com.cycling74.MaxMSP46 0x00038c64 app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 800 (main.c:1553)
16 com.apple.HIToolbox 0x931e5554 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
17 com.apple.HIToolbox 0x931e4cac SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
18 com.apple.HIToolbox 0x931eba60 SendEventToEventTarget + 40
19 com.apple.HIToolbox 0x932642cc SendHICommandEvent(unsigned long, HICommand const*, unsigned long, unsigned long, unsigned char, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 380
20 com.apple.HIToolbox 0×93294158 SendMenuItemSelectedEvent + 136
21 com.apple.HIToolbox 0x932af9d0 HandleKeyboardEvent(OpaqueEventRef*, unsigned char) + 340
22 com.apple.HIToolbox 0x931e5554 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
23 com.apple.HIToolbox 0x931e4cac SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
24 com.apple.HIToolbox 0x931e4b28 SendEventToEventTargetWithOptions + 40
25 com.apple.HIToolbox 0x932aece0 HandleKeyboardEvent(OpaqueEventRef*, unsigned long) + 320
26 com.apple.HIToolbox 0x931ebddc ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 512
27 com.apple.HIToolbox 0x931e57a4 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
28 com.apple.HIToolbox 0x931e4cac SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
29 com.apple.HIToolbox 0x931eba60 SendEventToEventTarget + 40
30 com.apple.HIToolbox 0x9322c7a0 ToolboxEventDispatcher + 92
31 com.apple.HIToolbox 0x9322c72c HLTBEventDispatcher + 16
32 com.apple.HIToolbox 0x9322ace4 RunApplicationEventLoop + 148
33 com.cycling74.MaxMSP46 0x0003859c app_run + 96 (main.c:1458)
34 com.cycling74.MaxMSP46 0×00038870 main + 704 (main.c:415)
35 com.cycling74.MaxMSP46 0x00001f5c _start + 340 (crt.c:272)
36 com.cycling74.MaxMSP46 0x00001e04 start + 60

[...]

Thread 0 crashed with PPC Thread State 64:
srr0: 0x000000000000ecb0 srr1: 0x100000000000f030 vrsave: 0×0000000000000000
cr: 0×44822202 xer: 0×0000000000000000 lr: 0x000000000000ecec ctr: 0x000000000000cd40
r0: 0×0000000080010058 r1: 0x00000000bfffdfe0 r2: 0×0000000080010058 r3: 0x00000000002d2400
r4: 0x00000000bfffe094 r5: 0×0000000000000050 r6: 0x00000000bfffe094 r7: 0x00000000000000e3
r8: 0x000000000000045c r9: 0x0000000031fdaf88 r10: 0×0000000000000000 r11: 0x000000000000045c
r12: 0x0000000090b92564 r13: 0×0000000000000002 r14: 0×0000000000000000 r15: 0x00000000a31e52b8
r16: 0×0000000031933920 r17: 0x00000000bffff3b0 r18: 0x00000000636d6473 r19: 0×0000000000000001
r20: 0x0000000000c26620 r21: 0x00000000ffffd96e r22: 0×0000000000000000 r23: 0x00000000bffff530
r24: 0×0000000000000001 r25: 0x000000000000045c r26: 0x00000000000000e3 r27: 0×0000000000000032
r28: 0x00000000002d3510 r29: 0x0000000031fdbd40 r30: 0x00000000bfffdfe0 r31: 0x00000000931e52b8

#30403
Feb 22, 2007 at 8:57am

What if you copy everything, paste it in a text editor and save the text file?

Mattijs

Quote: jbm wrote on Thu, 22 February 2007 09:00
—————————————————-
> Everytime I try to save my patch Max quits.

#97119
Feb 22, 2007 at 9:13am

I tried opening as text, saving with a different name, the reopening. I open it is a Max patch, but still saving it crashes Max. Always the same “0 com.cycling74.MaxMSP46 0x0000ecb0 binbuf_insert + 160 (binbuf.c:624)” as the final straw. I’ve also tried copying the text and doing New From Clipboard. Same thing. So it’s clearly somehow in the patch. What I don’t get is that I saved this successfully last night, when I last worked on it. I’ve tried saving to different locations as well…

J.

#97120
Feb 22, 2007 at 9:37am

I looked into binbuf_insert and it seems to be some sort of parser used in copying patchers — looks like it basically parses objects into Atoms of those funky little lines we see in our Max text files. To test this dodgy understanding, I tried copying all of the main window of my Max patch (as a patcher, not text), and sure enough, the same crash occurred, with the same “binbuf_insert” as the culprit.

So, you big-brained external writers (Peter, are you out there?), where might I start looking for the problem? From my sketchy understanding of binbuf_insert, I thought maybe a corrupt, embedded coll? Thoughts?

J.

#97121
Feb 22, 2007 at 9:41am

A quick glance at the crashlog suggests that you have a message box
with a LONG bit of text in it — more than 254 items, or containing
items longer than 255 characters, maybe more, which is crapping out
on save.

jb

Am 22.02.2007 um 09:13 schrieb jbmaxwell:

>
> I tried opening as text, saving with a different name, the
> reopening. I open it is a Max patch, but still saving it crashes
> Max. Always the same “0 com.cycling74.MaxMSP46 0x0000ecb0
> binbuf_insert + 160 (binbuf.c:624)” as the final straw. I’ve also
> tried copying the text and doing New From Clipboard. Same thing. So
> it’s clearly somehow in the patch. What I don’t get is that I saved
> this successfully last night, when I last worked on it. I’ve tried
> saving to different locations as well…
>
> J.

#97122
Feb 22, 2007 at 9:47am

Are you on a multiprocessor machine? I have a hunch that problems like
these sometimes go away after disabling one processor…
…Diemo

jbmaxwell wrote:
> Everytime I try to save my patch Max quits.
>
> Here’s the (hopefully) relevant crash report info:
>
> Thread 0 Crashed:
> 0 com.cycling74.MaxMSP46 0x0000ecb0 binbuf_insert + 160 (binbuf.c:624)
> 1 com.cycling74.MaxMSP46 0x0000cfdc atombuf_savebox + 572 (atombuf.c:568)
> 2 com.cycling74.MaxMSP46 0x00106d58 vmessage_psave(_vmessage*, void*) + 244 (vmessage.c:299)
> 3 com.cycling74.MaxMSP46 0x00017d18 box_save + 84 (box.c:1146)
> 4 com.cycling74.MaxMSP46 0x0004cda4 patcher_save + 612 (patcher.c:1305)
> 5 com.cycling74.MaxMSP46 0x00108fd8 vnewobj_psave(vnewobj*, void*) + 352 (vnewobj.c:325)
> 6 com.cycling74.MaxMSP46 0x00017d18 box_save + 84 (box.c:1146)
> 7 com.cycling74.MaxMSP46 0x0004cda4 patcher_save + 612 (patcher.c:1305)
> 8 com.cycling74.MaxMSP46 0x00108fd8 vnewobj_psave(vnewobj*, void*) + 352 (vnewobj.c:325)
> 9 com.cycling74.MaxMSP46 0x00017d18 box_save + 84 (box.c:1146)
> 10 com.cycling74.MaxMSP46 0x0004cda4 patcher_save + 612 (patcher.c:1305)
> 11 com.cycling74.MaxMSP46 0x00057d1c patcher_saveto + 124 (patchermenu.c:587)
> 12 com.cycling74.MaxMSP46 0x0009c670 wind_save + 192 (window.c:1780)
> 13 com.cycling74.MaxMSP46 0x000a0b50 wind_filemenu + 236 (window.c:1300)
> 14 com.cycling74.MaxMSP46 0x00041b48 menu_dobar + 732 (menu.c:793)
> 15 com.cycling74.MaxMSP46 0x00038c64 app_eventhandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 800 (main.c:1553)
> 16 com.apple.HIToolbox 0x931e5554 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
> 17 com.apple.HIToolbox 0x931e4cac SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
> 18 com.apple.HIToolbox 0x931eba60 SendEventToEventTarget + 40
> 19 com.apple.HIToolbox 0x932642cc SendHICommandEvent(unsigned long, HICommand const*, unsigned long, unsigned long, unsigned char, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 380
> 20 com.apple.HIToolbox 0×93294158 SendMenuItemSelectedEvent + 136
> 21 com.apple.HIToolbox 0x932af9d0 HandleKeyboardEvent(OpaqueEventRef*, unsigned char) + 340
> 22 com.apple.HIToolbox 0x931e5554 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
> 23 com.apple.HIToolbox 0x931e4cac SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
> 24 com.apple.HIToolbox 0x931e4b28 SendEventToEventTargetWithOptions + 40
> 25 com.apple.HIToolbox 0x932aece0 HandleKeyboardEvent(OpaqueEventRef*, unsigned long) + 320
> 26 com.apple.HIToolbox 0x931ebddc ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 512
> 27 com.apple.HIToolbox 0x931e57a4 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
> 28 com.apple.HIToolbox 0x931e4cac SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
> 29 com.apple.HIToolbox 0x931eba60 SendEventToEventTarget + 40
> 30 com.apple.HIToolbox 0x9322c7a0 ToolboxEventDispatcher + 92
> 31 com.apple.HIToolbox 0x9322c72c HLTBEventDispatcher + 16
> 32 com.apple.HIToolbox 0x9322ace4 RunApplicationEventLoop + 148
> 33 com.cycling74.MaxMSP46 0x0003859c app_run + 96 (main.c:1458)
> 34 com.cycling74.MaxMSP46 0×00038870 main + 704 (main.c:415)
> 35 com.cycling74.MaxMSP46 0x00001f5c _start + 340 (crt.c:272)
> 36 com.cycling74.MaxMSP46 0x00001e04 start + 60
>
>
> [...]
>
>
> Thread 0 crashed with PPC Thread State 64:
> srr0: 0x000000000000ecb0 srr1: 0x100000000000f030 vrsave: 0×0000000000000000
> cr: 0×44822202 xer: 0×0000000000000000 lr: 0x000000000000ecec ctr: 0x000000000000cd40
> r0: 0×0000000080010058 r1: 0x00000000bfffdfe0 r2: 0×0000000080010058 r3: 0x00000000002d2400
> r4: 0x00000000bfffe094 r5: 0×0000000000000050 r6: 0x00000000bfffe094 r7: 0x00000000000000e3
> r8: 0x000000000000045c r9: 0x0000000031fdaf88 r10: 0×0000000000000000 r11: 0x000000000000045c
> r12: 0x0000000090b92564 r13: 0×0000000000000002 r14: 0×0000000000000000 r15: 0x00000000a31e52b8
> r16: 0×0000000031933920 r17: 0x00000000bffff3b0 r18: 0x00000000636d6473 r19: 0×0000000000000001
> r20: 0x0000000000c26620 r21: 0x00000000ffffd96e r22: 0×0000000000000000 r23: 0x00000000bffff530
> r24: 0×0000000000000001 r25: 0x000000000000045c r26: 0x00000000000000e3 r27: 0×0000000000000032
> r28: 0x00000000002d3510 r29: 0x0000000031fdbd40 r30: 0x00000000bfffdfe0 r31: 0x00000000931e52b8
>


Diemo Schwarz, PhD — http://diemo.concatenative.net
Real-Time Music Interaction Team — http://www.ircam.fr/equipes/temps-reel
IRCAM – Centre Pompidou — 1, place Igor-Stravinsky, 75004 Paris, France
Phone +33-1-4478-4879 — Fax +33-1-4478-1540

#97123
Feb 22, 2007 at 9:49am

HAHA!!!! Found it!

I had an Laccum object which had output the rather suspicious message “0 ??? ??? ??? ??? ???” — I guess because it was lacking data for a list of predetermined length(??) Not sure. Anyway, clearing that message fixed it. I guess binbuf_insert couldn’t deal with the “???” string in a message box… Maybe? Can that be fixed, David? Not that it’s a huge deal, and I personally won’t let it happen again, but I’m assuming that if it can be put in a message box, it should be copyable and saveable…

Anyway, my sanity’s is temporarily restored.

In case anyone gets into a similar problem, I just went through each subpather, selecting and copying. Whatever crashed Max must have had nasties in it. Sherlock Holmes? Bah! A Debutante!

J.

[ EDIT ] — just got your message jb, thanks! All’s well now.

#97124
Feb 22, 2007 at 9:52am

BTW, jb. It wasn’t a terribly long message. I think 74 members. So it must have been the “???”s that pooched binbuf_insert.

J.

#97125
Feb 22, 2007 at 10:00am

The ???s were garbage data which couldn’t be stored, then. I wonder
what Laccum was kicking out. Anyway, good that you found the problem.

jb

Am 22.02.2007 um 09:52 schrieb jbmaxwell:

>
> BTW, jb. It wasn’t a terribly long message. I think 74 members. So
> it must have been the “???”s that pooched binbuf_insert.
>
> J.

#97126
Feb 22, 2007 at 10:07am

just a guess, but I imagine this is a pretty complex patch? Have you tried disconnected subpatches to see if it prevents the problem?

#97127
Feb 22, 2007 at 11:06am

On 22-Feb-2007, at 9:37, jbmaxwell wrote:
> Peter, are you out there?

You mean me? Like the truth, I’m out there somewhere. In my case just
in a different time zone. Reading the thread after breakfast it seems
you’ve solved the problem.

About binbufs: they are documented to some extent in the SDK. You are
correct in your analysis that they, and in particular the call to
binbuf_insert(), are involved in saving and copying patches. But
insight into implementation details is restricted to Those Chosen Few
Who Write the Max Source Code.

You might want to check with Peter Elsea about Laccum’s output. The
thing is, normally lots of question marks in a message box won’t
cause a crash. The LObjects are pretty robust, but if something is
causing binbuf_insert() to crash, I would look upstream.

– One of the many Peters

#97128
Feb 22, 2007 at 11:51am

>
> — One of the many Peters
>

heh… No, you are the Peter. Maybe you can start referring to yourself in the third-person, like “The Rock”. I don’t think you need to take up wrestling — he’s mostly just a bad actor now. How are your acting chops, btw?

J.

#97129
Feb 24, 2007 at 1:48pm

Just a note to Mr. Elsea. The Laccum is occasionally putting out garbage data — it shows up in message boxes as “??? ??? ???”. As noted in this thread, it was causing binbuf_insert problems, which was causing Max to quit on save. However, it just did it to me again, and this time, rather than having simply quit Max, it actually truncated the file to disc, overwriting my past 3 hours work… very sad.

It seems to have something to do with entering a shorter list in the left inlet than the typed-in argument. Obviously, this is not something I generally intend to do, but I think it could still be considered a bug(?) If Laccum could at least pad its stored list out with zeros to prevent the garbage data maybe that would do the trick? I do think it’s only when the garbage data gets printed to a message box that the crashing happens, but I commonly use a [prepend set -> message box] to monitor Laccum’s output, so it would be great if this ‘garbage data’ problem could be fixed.

thanks,

J.

#97130
Apr 26, 2007 at 11:57pm

Finally surfacing– The forum is just too big for me to read everything, so I search on the word Lobject from time to time. Please write directly to me when you find bugs like this.
I can’t reproduce this behavior in Laccum– what you are supposed to get is a list the length of the longest list seen since a clear. Please mail the horrid details.

??? is an unknown atom type. This was harmless until Max 4, when suddenly opening any binbuf with one (including a patch saved with ??? in a message) would kill Max.

#97131

You must be logged in to reply to this topic.