< Back to IRCAM Forum

Segmentation violation error

OpenMusic
#1

Hi,
I’m using OM 6.11 on a Mac Pro 6-Core Intel Xeon E5 running El Capitan 10.11.4, and when I evaluate the sdiffile box to load a 1TRC sdif like the one here attached I get this error:

Error while evaluating the box SDIFFILE : Segmentation violation(11) [code 0] at 109BE0673
Foreign code offset #x4B from symbol “SdifMatrixTypeGetNthColumnDef”
module “/Applications/OM 6.11/OM 6.11.app/Contents/Frameworks/libSDIF.dylib” [ #x109BD2000 ]
rax 6F646E69576E6565 ; rbx 100635850 ; rcx 1 ; rdx 41101D2800
rsp 700000408B80 ; rbp 700000408BA0 ; rdi 100635870 ; rsi 1
r8 40E0BDE7AA ; r9 40D01B4C39 ; r10 40400B25EB ; r11 109BE068A
r12 1E73D ; r13 100553120 ; r14 1 ; r15 0

So, what could be the reason of this issue (excluding the library conflicts, because I have only the OMChroma, Prisma and pm2 libraries loaded)?
Best,
Francesco

bell.sdif_.zip (102 KB)

#2

After many trials and fails, I came to the conclusion that errors like the one here mentioned are caused by OM 6.11 not behaving well with .ome files stored in the “user” folder of the workspace. Thus the question I pose to Jean is: why OM 6.11 has so much trouble in handling graphical methods?
All the best,
Francesco

#3

Graphical methods are evaluated at startup, probably initializing in this case some parts of the SDIF framework earlier than usual (when you use it from a patch).

The SDIF library has been updated in OM 6.11: maybe some types that are redefined in one of these graphical methods are now part of the standard ?
I will try to figure out the changes brought by this library update.

#4

In particular, as Jean suggests, the .ome depending on the SDIF library could be the cause of the errors. The SDIF library has been updated, and the .ome could contain types of SDIF that in previous versions of OM had to be declared, while now these types are included in OM by default. Now I suggest that, even if the types are included by default, one should be able to declare them without trouble (instead of having to rebuild the .ome files ex nihilo which could be in certain cases a pretty difficult task!)
Best,
Francesco

#5

Jean has PM me: "after further checks : I think this has nothing to do with the types.
just about when the SDIF library is initialized.

you can reproduce your problem with any kind of SDIF file, just having and SDIFFrame object in one of the .ome files"

#6

I was misled by the “OM 6.11” part of the crash report : I think the same would happen in any previous version of OM.
This is an old issue that I have never been really able to explain : the SDIF library (not only the recent update) must be initialized at a relatively late stage of the overall OM initialization chain, otherwise the kind of crash you experimented systematically tends to happen.
The current “hack” is that SDIF is initialized the first time you need it (that is, when you open a patch containing an SDIF object, or when you create one in a patch). Evaluation of graphical methods happens at the beginning of the OM session, which is apparently still too early.

#7

I think the attached file (copied in OM 6.x/patches/) should make the trick and delay SDIF initialization

sdif-init-delayed.lisp (206 Bytes)

#8

Many thanks Jean. Honestly, in earlier versions of OM, I didn’t encounter this problem. So the “6.11” report was legit to me. I’ll see if your .lisp works: meanwhile, thanks again for your patience.

#9

Dear Jean,
unfortunately, with your .lisp file, when I try to open a patch in the workspace I get this error: “An error of type undefined-function occurred: Undefined operator sdif-package::sdif-init-cond in form (sdif-package::sdif-init-cond)”. I guess there’s something wrong with the fix…

#10

A quick update: most of the time, OM behaves well with the fix, but the error keeps appearing without any reason in some cases just when trying to open some patches. Is there an explanation or a solution?
Best,
Francesco