denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Denemo Crashing after git pull


From: Richard Shann
Subject: Re: [Denemo-devel] Denemo Crashing after git pull
Date: Fri, 17 Oct 2014 17:53:54 +0100

and yet another:
Program received signal SIGSEGV, Segmentation fault.
0x000000000047c419 in find_xes_in_measure (address@hidden, 
    measurenum=1, time1=4, time2=4)
    at ../../denemo/src/display/calculatepositions.c:365
365           fxim_utility; //creates the non_chords list up to the first
chord, moving cur_obj_nodes to the first chord in each staff
(gdb) where
#0  0x000000000047c419 in find_xes_in_measure (address@hidden, 
    measurenum=1, time1=4, time2=4)
    at ../../denemo/src/display/calculatepositions.c:365
#1  0x0000000000421b96 in displayhelper (gui=0x1edede0)
    at ../../denemo/src/command/commandfuncs.c:1910
#2  displayhelper (gui=0x1edede0)
    at ../../denemo/src/command/commandfuncs.c:1902
#3  0x00000000004226f9 in object_insert (address@hidden, 
    address@hidden)
    at ../../denemo/src/command/commandfuncs.c:325
#4  0x0000000000423ad4 in dnm_insertchord (gui=0x1edede0, 
    duration=<optimized out>, mode=<optimized out>, address@hidden)
    at ../../denemo/src/command/commandfuncs.c:1684
#5  0x000000000042628a in insert_chord_xkey (duration=<optimized out>, 
    param=<optimized out>)
at ../../denemo/src/command/keyresponses.c:606
#6  0x000000000042208f in insert_note_following_pattern (
    address@hidden)
at ../../denemo/src/command/commandfuncs.c:1406
#7  0x00000000004222ac in shiftcursor (gui=0x1edede0, note_value=5)
    at ../../denemo/src/command/commandfuncs.c:1504

I had a look through the data values and found a corrupt pointer - it
was one with the top 32 bits set. We have had random crashes before
caused by not having a header file included - the function was returning
a pointer (64-bits) but, by default was assumed to be returning an int
(32-bits). It seemed that the randomness came about because sometimes
the pointer fitted in 32-bits, sometimes not. (That time it was the use
of the modulation wheel to change the enharmonic set that randomly
crashed, under another file re-organization the lack of a prototype for
the function became critical).
So, one possibility is that Denemo may be working reliably under 32-bit
processors, if anyone is in a position to test (difficult to test of
course, one would need to be using the program for a while to gain
confidence...)
Contrariwise, if anyone has a 64 bit machine and would volunteer to test
that would be good.

Richard



On Fri, 2014-10-17 at 12:33 +0100, Richard Shann wrote:
> Another crash while deleting:
> 
> #0  find_context_of_object (address@hidden, si=<optimized
> out>, 
>     si=<optimized out>) at ../../denemo/src/command/contexts.c:69
> #1  0x0000000000424441 in get_clef_before_object (obj=<optimized out>)
>     at ../../denemo/src/command/contexts.c:94
> #2  0x000000000041ff16 in beamandstemdirhelper (address@hidden)
>     at ../../denemo/src/command/commandfuncs.c:111
> #3  0x0000000000421b60 in displayhelper (gui=0x1fdc7f0)
>     at ../../denemo/src/command/commandfuncs.c:1908
> #4  displayhelper (gui=0x1fdc7f0)
>     at ../../denemo/src/command/commandfuncs.c:1902
> #5  0x00000000004235c6 in dnm_deleteobject (si=0x383a7a0)
>     at ../../denemo/src/command/commandfuncs.c:2471
> #6  0x00000000004237a3 in deleteobject (address@hidden, 
>     address@hidden)
> at ../../denemo/src/command/commandfuncs.c:2325
> #7  0x00000000004265c7 in deletepreviousobject (action=<optimized out>, 
>     param=<optimized out>)
> at ../../denemo/src/command/keyresponses.c:812
> 
> I had a file which repeatedly crashed Denemo when I tried to open it -
> after a while the behavior went away, it now opens ok.
> 
> Richard
> 
> 
> On Thu, 2014-10-16 at 16:44 +0100, Richard Shann wrote:
> > On Thu, 2014-10-16 at 16:26 +0200, Éloi Rivard wrote:
> > > I look at this asap.
> > 
> > One thing occurs to me (glancing over the changes), there is a set of
> > functions called dnm_xxx which was part of an uncompleted development
> > that Adam Tee and Jeremiah were involved in to create a plug-in
> > interface. I seem to recall that some of these were never properly
> > debugged and should not be called. 
> > Coming to the code from the outside it might be tempting to replace
> > calls that work with calls to these official-looking functions with
> > insidious consequences... Others of them did become mainstream code,
> > though.
> > 
> > Richard
> > 
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/denemo-devel
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]