Group Admins

  • Profile picture of Karim
  • Profile picture of Jean

OpenMusic

Public Group active 2 days, 12 hours ago

User group for OpenMusic and computer-aided composition. Visit the Forum for discussions.

Segmentation violation error

Author 2 Subscribed Users |
Profile photo of Francesco Vitale
Francesco Vitale

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

Attachments:
  1. bell.sdif_.zip
December 18, 2016 at 23:02 #20277
Profile photo of Francesco Vitale
Francesco Vitale

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

January 3, 2017 at 11:22 #20354
Profile photo of Jean
Jean

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.

January 3, 2017 at 11:27 #20355
Profile photo of Francesco Vitale
Francesco Vitale

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

January 3, 2017 at 11:36 #20356
Profile photo of Francesco Vitale
Francesco Vitale

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”

January 3, 2017 at 11:52 #20357
Profile photo of Jean
Jean

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.

January 3, 2017 at 12:07 #20359
Profile photo of Jean
Jean

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

January 3, 2017 at 12:13 #20360
Profile photo of Francesco Vitale
Francesco Vitale

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.

January 3, 2017 at 12:47 #20371
Profile photo of Francesco Vitale
Francesco Vitale

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…

January 3, 2017 at 13:11 #20374
Profile photo of Francesco Vitale
Francesco Vitale

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

January 5, 2017 at 10:31 #20389

You must be logged in to reply to this topic.

Log in now