Re: [Denemo-devel] Denemo crash on startup

[Richard Shann]

On Wed, 2018-12-05 at 21:33 +0100, Andreas Schneider wrote:
> Hi,
> 
> after updating to the newest version from git, Denemo crashes with a
> segmentation fault on startup (after having said No to the question
> whether to re-use existing commands, shortcuts, etc.), 

That is the bit that was causing the crash - in the absence of recently
opened files it crashes :(
I've fixed it now in git.

Richard


> see the traceback
> below. Do you have an idea what might cause that? My OS is Debian
> Stretch (9.6).
> 
> Andreas
> 
> 
> (gdb) run
> Starting program: /usr/bin/denemo
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-
> gnu/libthread_db.so.1".
> Denemo data expected in /usr/share/denemo/
> [New Thread 0x7fffdae40700 (LWP 19606)]
> [New Thread 0x7fffda63f700 (LWP 19607)]
> [New Thread 0x7fffd9e3e700 (LWP 19608)]
> [New Thread 0x7fffd963d700 (LWP 19609)]
> [New Thread 0x7fffd8e3c700 (LWP 19610)]
> [New Thread 0x7fffd863b700 (LWP 19611)]
> [New Thread 0x7fffd7e3a700 (LWP 19612)]
> [New Thread 0x7fffd6d08700 (LWP 19613)]
> [New Thread 0x7fffd6507700 (LWP 19614)]
> Gtk-Message: GtkDialog mapped without a transient parent. This is
> discouraged.
> Denemo - WARNING : No syntax highlighting for LilyPond
> Denemo - MESSAGE : Audio driver is 'portaudio'
> Denemo - MESSAGE : Initializing Fluidsynth
> Denemo - MESSAGE : The default fluidsynth soundfont has been loaded
> Denemo - MESSAGE : Initializing PortAudio backend
> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM
> cards.pcm.rear
> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM
> cards.pcm.center_lfe
> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM
> cards.pcm.side
> ALSA lib pcm_route.c:867:(find_matching_chmap) Found no matching
> channel map
> [New Thread 0x7fffd4c91700 (LWP 19743)]
> Cannot connect to server socket err = No such file or directory
> Cannot connect to server request channel
> jack server is not running or cannot be started
> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
> 4294967295, skipping unlock
> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
> 4294967295, skipping unlock
> [Thread 0x7fffd4c91700 (LWP 19743) exited]
> Denemo - MESSAGE : Opening output device 'ALSA: default'
> [New Thread 0x7fffc7fff700 (LWP 19744)]
> Denemo - MESSAGE : MIDI driver is 'portmidi'
> Denemo - MESSAGE : Initializing PortMidi backend
> [New Thread 0x7fffc77fe700 (LWP 19745)]
> Denemo - MESSAGE : Opening input device 'ALSA: Midi Through Port-0'
> Denemo - MESSAGE : Opening output device 'ALSA: Midi Through Port-0'
> [New Thread 0x7fffc6ffd700 (LWP 19746)]
> Denemo - MESSAGE : Denemo version 2.2.10
> Denemo - MESSAGE : Loaded keymap
> /home/src/denemo/actions/Default.commands
> switching pagenum 0
> switching pagenum 0
> switching pagenum 0
> 
> Thread 1 "denemo" received signal SIGSEGV, Segmentation fault.
> 0x555e33aa in ?? ()
> (gdb) where
> #0  0x555e33aa in ?? ()
> #1  0x556084ed in ?? ()
> #2  0x555ec39a in ?? ()
> #3  0x77a5cadc in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #4  0x77b0ce36 in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #5  0x77adeca0 in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #6  0x77b174f3 in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #7  0x77b37f08 in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #8  0x77a675ab in scm_call_4 ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #9  0x77b0cc8c in scm_catch_with_pre_unwind_handler ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #10 0x77b0cf0e in scm_c_catch ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #11 0x77a5c92b in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #12 0x77a5cbf4 in scm_c_with_continuation_barrier ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> ---Type  to continue, or q  to quit---
> #13 0x77b09bea in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #14 0x777913c2 in GC_call_with_stack_base ()
>    from /usr/lib/x86_64-linux-gnu/libgc.so.1
> #15 0x77b09cd3 in ?? ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #16 0x77b09d13 in scm_with_guile ()
>    from /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #17 0x5557c58a in main ()
> (gdb)
> 
> ___
> Denemo-devel mailing list
> Denemo-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/denemo-devel

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash on startup

[Richard Shann]

On Wed, 2018-12-05 at 21:33 +0100, Andreas Schneider wrote:
> Hi,
> 
> after updating to the newest version from git, Denemo crashes with a
> segmentation fault on startup (after having said No to the question
> whether to re-use existing commands, shortcuts, etc.), see the
> traceback
> below. Do you have an idea what might cause that?

As a first step could you break on inner_main in gdb, that is

b inner_main

and then run

r

and see if it crashes before that, if it does stop on inner_main can
you keep pressing next

n

until it does crash.

Richard


___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Thu, 2017-02-09 at 08:50 +0100, Andreas Schneider wrote:
> Am 08.02.2017 um 10:09 schrieb Richard Shann:
> > On Tue, 2017-02-07 at 23:40 +0100, Andreas Schneider wrote:
> >>> is that a parameter to the configure script? That might well turn
[...]
> > 
> > But first, check that voices can have lyrics typeset on them since if
> > not we have a version-confusion problem.
> 
> I did this check and saw that the debugging version did typeset the
> second lyrics line, but the crashing version did not typeset the second
> lyrics line. Looking closer I saw that by mistake I had installed the
> 2.0.19 package still lurking around instead of the 2.0.21 package that I
> had just built. After installing the correct package, everything works
> fine. I'm very sorry for the noise, mea culpa.

That's really good news, I was beginning to worry that we had a stray
pointer somewhere.
 I've pushed the latest work to git now, it is mostly an internal purge
of old obfuscating code dating back to the days when Denemo had various
entry modes, but also various minor fixes prompted by Joe Wilkinson's
comments. The version now becomes 2.0.23 which can be checked using
Help->About on starting, or looking at the terminal output.

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 08.02.2017 um 10:09 schrieb Richard Shann:
> On Tue, 2017-02-07 at 23:40 +0100, Andreas Schneider wrote:
>>> is that a parameter to the configure script? That might well turn
>> off
>>> the optimizer too.
>>
>> Yes, I meant an additional parameter to the configure script
> 
> So it probably turned off the optimizer, which then perturbed the code
> generation, which then (fortuitously) worked.
> 
> The plain ./configure without the --enable-debug option is what you need
> - it generates the debug information and uses the default optimization.
> 
>  You just need to use the binary before the symbols are stripped.
> It should then behave exactly as the stripped executable, but when it
> crashes you will get better information about where it was when it
> crashed and will be able to set breakpoints. 
> 
> But first, check that voices can have lyrics typeset on them since if
> not we have a version-confusion problem.

I did this check and saw that the debugging version did typeset the
second lyrics line, but the crashing version did not typeset the second
lyrics line. Looking closer I saw that by mistake I had installed the
2.0.19 package still lurking around instead of the 2.0.21 package that I
had just built. After installing the correct package, everything works
fine. I'm very sorry for the noise, mea culpa.

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Tue, 2017-02-07 at 23:40 +0100, Andreas Schneider wrote:
> > is that a parameter to the configure script? That might well turn
> off
> > the optimizer too.
> 
> Yes, I meant an additional parameter to the configure script

So it probably turned off the optimizer, which then perturbed the code
generation, which then (fortuitously) worked.

The plain ./configure without the --enable-debug option is what you need
- it generates the debug information and uses the default optimization.

 You just need to use the binary before the symbols are stripped.
It should then behave exactly as the stripped executable, but when it
crashes you will get better information about where it was when it
crashed and will be able to set breakpoints. 

But first, check that voices can have lyrics typeset on them since if
not we have a version-confusion problem.

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Tue, 2017-02-07 at 23:42 +0100, Andreas Schneider wrote:
> >> Do you mean Staffs/Voices > Voices > Add Voice?
> > 
> > Does it always do this? That is if you start with an empty score?
> 
> No, Denemo does not crash when applying Add Voice to an empty score.

OK, if you then add a verse to the *voice* does it typeset? That is, you
should be able to add verses to both Denemo staffs and both should
print.
[This is (as always) using the version that crashes when you have your
Hard Day's Night score loaded and try to do things such as deleting the
last verse].

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 07.02.2017 um 23:10 schrieb Richard Shann:
> On Tue, 2017-02-07 at 21:30 +0100, Andreas Schneider wrote:
>>> Could you make the following check:
>>>
>>> start the version of the program that crashes when trying to delete
>> the
>>> last verse. Create a voice to a staff and add a verse to it. Typeset
>> the
>>> score and see if the verse that is attached to the voice is typeset.
>>
>> Do you mean Staffs/Voices > Voices > Add Voice?
> 
> Does it always do this? That is if you start with an empty score?

No, Denemo does not crash when applying Add Voice to an empty score.

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 07.02.2017 um 23:11 schrieb Richard Shann:
> On Tue, 2017-02-07 at 21:34 +0100, Andreas Schneider wrote:
>> The difference is that I compiled with the additional flag
>> --enable-debug 
> 
> is that a parameter to the configure script? That might well turn off
> the optimizer too.

Yes, I meant an additional parameter to the configure script

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Tue, 2017-02-07 at 21:34 +0100, Andreas Schneider wrote:
> The difference is that I compiled with the additional flag
> --enable-debug 

is that a parameter to the configure script? That might well turn off
the optimizer too.

Richard




___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Tue, 2017-02-07 at 21:30 +0100, Andreas Schneider wrote:
> > Could you make the following check:
> > 
> > start the version of the program that crashes when trying to delete
> the
> > last verse. Create a voice to a staff and add a verse to it. Typeset
> the
> > score and see if the verse that is attached to the voice is typeset.
> 
> Do you mean Staffs/Voices > Voices > Add Voice?

Does it always do this? That is if you start with an empty score?

Richard




___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 07.02.2017 um 10:33 schrieb Richard Shann:
> [...]
>
> I guess you have to have the flag set for debug symbols for the
> breakpoint to get set (IIRC the flag is -B for gcc).
> 
> ... and reading a later email, you turned on debug symbols and the
> program didn't crash. This *really* shouldn't happen - the actual
> executing code is supposed to be completely unchanged with or without
> debug information included - it's like getting a car with or without a
> user's manual, the car is supposed to be identical. This would be a gcc
> bug, but I would check that you didn't do something else at the same
> time as turning on debug symbols (e.g. change -O2 )

The difference is that I compiled with the additional flag
--enable-debug and that the scripts for building the packages did not
run (which, e.g., strip the binary).

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 07.02.2017 um 11:19 schrieb Richard Shann:
> On Sun, 2017-02-05 at 22:02 +0100, Andreas Schneider wrote:
>> Thread 1 "denemo" received signal SIGINT, Interrupt.
>> 0x71fb754d in poll () at ../sysdeps/unix/syscall-template.S:84
>> (gdb) b select.c:1176
>> Make breakpoint pending on future shared library load? (y or [n])
> 
> So the other crash that you tested failed to stop for the same reason -
> the breakpoint was never set on anything gdb knew about.
> 
> Could you make the following check:
> 
> start the version of the program that crashes when trying to delete the
> last verse. Create a voice to a staff and add a verse to it. Typeset the
> score and see if the verse that is attached to the voice is typeset.

Do you mean Staffs/Voices > Voices > Add Voice? The program crashes when
I activate that command. See attached log.

> The point of this is that if this fails to typeset the verse on the
> voice then the version you are compiling is not the latest git
> development, as typesetting verses on voices was fixed after the
> crash-on-deleting-last-verse was fixed.

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from denemo...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/denemo 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdb3e7700 (LWP 1787)]
[New Thread 0x7fffdabe6700 (LWP 1788)]
[New Thread 0x7fffda3e5700 (LWP 1789)]
[New Thread 0x7fffd9be4700 (LWP 1790)]
[New Thread 0x7fffd93e3700 (LWP 1791)]
[New Thread 0x7fffd8be2700 (LWP 1792)]
[New Thread 0x7fffd83e1700 (LWP 1793)]
[New Thread 0x7fffd72f7700 (LWP 1794)]
[New Thread 0x7fffd7276700 (LWP 1795)]
Denemo - MESSAGE : Loading preference file: /home/andreas/.denemo-2.0.21/denemorc
Denemo - MESSAGE : Audio driver is 'jack'
Denemo - MESSAGE : Initializing JACK audio backend
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackPosixSemaphore::Connect name = jack_sem.2000_default_denemo
Jack: JackPosixSemaphore::Connect sem_getvalue 0
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = denemo refnum = 2
Jack: JackClient::Activate
Jack: JackPosixThread::StartImp : create non RT thread
[New Thread 0x7fffd71e3700 (LWP 1796)]
Jack: JackPosixThread::ThreadHandler : start
Jack: JackClient::kBufferSizeCallback buffer_size = 1024
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 2
Jack: JackClient::kActivateClient name = denemo ref = 2 
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Denemo - MESSAGE : The default fluidsynth soundfont has been loaded
Jack: JackClient::PortRegister ref = 2 name = denemo:in_1 type = 32 bit float mono audio port_index = 5
Jack: JackClient::PortRegister ref = 2 name = denemo:out_1 type = 32 bit float mono audio port_index = 6
Jack: JackClient::PortRegister ref = 2 name = denemo:out_2 type = 32 bit float mono audio port_index = 7
Jack: JackClient::Connect src = denemo:out_1 dst = system:playback_1
Jack: JackClient::Connect src = denemo:out_2 dst = system:playback_2
[New Thread 0x7fffd6879700 (LWP 1797)]
Denemo - MESSAGE : MIDI driver is 'portmidi'
Denemo - MESSAGE : Initializing PortMidi backend
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
[New Thread 0x7fffd5e65700 (LWP 1798)]
[New Thread 0x7fffd4ff2700 (LWP 1799)]
[New Thread 0x7fffcb188700 (LWP 1800)]
Denemo - MESSAGE : Opening input device 'ALSA: Midi Through Port-0'
Denemo - MESSAGE : Opening output device 'ALSA: Midi Through Port-0'
Denemo - MESSAGE : Denemo version 2.0.21
Denemo - MESSAGE : Loaded keymap /home/andreas/.denemo-2.0.21/actions/Default.commands
Denemo - MESSAGE : Reading history file /home/andreas/.denemo-2.0.21/denemohistory
Success 1
[New Thread 0x7fffca987700 (LWP 1801)]
[New Thread 0x7fffca186700 (LWP 1802)]
Denemo - MESSAGE : Opening file 

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Mon, 2017-02-06 at 21:28 +0100, Andreas Schneider wrote:
> >   make clean && make 2>&1 | tee make.log
> > 
> > to be sure that there are no warnings being ignored.
> 
> You find the output of make attached to this mail.

This has flagged up some interesting things to fix, but nothing
dangerous, I'll wait until the internal re-write code is merged before
tackling those. Thanks!

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Sun, 2017-02-05 at 22:02 +0100, Andreas Schneider wrote:
> Thread 1 "denemo" received signal SIGINT, Interrupt.
> 0x71fb754d in poll () at ../sysdeps/unix/syscall-template.S:84
> (gdb) b select.c:1176
> Make breakpoint pending on future shared library load? (y or [n])

So the other crash that you tested failed to stop for the same reason -
the breakpoint was never set on anything gdb knew about.

Could you make the following check:

start the version of the program that crashes when trying to delete the
last verse. Create a voice to a staff and add a verse to it. Typeset the
score and see if the verse that is attached to the voice is typeset.

The point of this is that if this fails to typeset the verse on the
voice then the version you are compiling is not the latest git
development, as typesetting verses on voices was fixed after the
crash-on-deleting-last-verse was fixed.

I have a substantial internal upgrade of the code ready to commit, but
I'm holding off so as to not muddy the picture. I could bump the Denemo
version now, but it would be better to do it after I commit this
upgrade.

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Sun, 2017-02-05 at 22:08 +0100, Andreas Schneider wrote:
> Am 03.02.2017 um 18:26 schrieb Richard Shann:
> > On Thu, 2017-02-02 at 23:33 +0100, Andreas Schneider wrote:
> >>> Also, if you delete the lyrics from the score I expect the problem
> >> may
> >>> go - it was the snapshotting of the lyrics that had serious bugs.
> >>
> >> When deleting the last lyrics verse, Denemo crashes, even after
> >> executing (d-IncreaseGuard). See attached log file.
> > 
> > This is quite surprising! There was such a bug, a regression from 2.0.14
> > which I fixed on Wed, 1 Feb 2017 14:23:52 +
> > 
> > If you set a breakpoint in lyric.c at line 689
> > 
> > b lyric.c:689
> > 
> > the it should stop on that line when you delete the last verse...
> > 
> > and then
> > 
> >  p staff->current_verse_view
> > 
> > should show an empty GList* for the current_verse_view.
> 
> Again, Denemo seems to crash before it reaches the breakpoint, see
> attached log.
Ah, the problem here is that the break point was never set - in your
terminal log you have:

[...]
(gdb) b lyric.c:689
Make breakpoint pending on future shared library load? (y or [n]) 
(gdb) c


The meaning of the question is that gdb has not got any idea where
lyric.c:689 is, and is hoping it is perhaps in some yet-to-be-loaded
library. We *know* it is in the actual program.

I guess you have to have the flag set for debug symbols for the
breakpoint to get set (IIRC the flag is -B for gcc).

... and reading a later email, you turned on debug symbols and the
program didn't crash. This *really* shouldn't happen - the actual
executing code is supposed to be completely unchanged with or without
debug information included - it's like getting a car with or without a
user's manual, the car is supposed to be identical. This would be a gcc
bug, but I would check that you didn't do something else at the same
time as turning on debug symbols (e.g. change -O2 )

Richard




___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Mon, 2017-02-06 at 08:50 +0100, Andreas Schneider wrote:
> I have now seen that the version with debug informations does not
> crash.
> So it might have something to do with the optimisation?

Well optimization is done independently of creating and storing debug
information. To test without optimization I edit the file src/Makefile
at the line


CFLAGS = -g -O2 -fdiagnostics-color=auto   -I/usr/include/glib-2.0 ... 

to read

CFLAGS = -g -O0 -fdiagnostics-color=auto   -I/usr/include/glib-2.0 ... 

(It's quite extraordinary, but I've never noticed any performance change
when running like that! But debugging is much easier).

It'll take me a little while to work out what to do next (we *may* be
chasing some bug that is not actually in Denemo, but the fact that it
happens while exercising code that I have recently altered is highly
suspicious of some un-initialized pointer). Bear with me.
Meanwhile it might be worthwhile to generate another 

make clean && make 2>&1 | tee make.log

to be sure that there are no warnings being ignored.

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 06.02.2017 um 08:45 schrieb Andreas Schneider:
> Am 05.02.2017 um 22:02 schrieb Andreas Schneider:
>> Am 03.02.2017 um 17:47 schrieb Richard Shann:
>>> On Thu, 2017-02-02 at 23:33 +0100, Andreas Schneider wrote:
 Am 01.02.2017 um 22:48 schrieb Richard Shann:
> yes, but it could be a bug in Denemo that happens not to be
 triggered. 
> Can you try executing
> (d-IncreaseGuard) in the Scheme window or CLI and then seeing if it
> crashes? d- IncreaseGaurd will turn off the undo, and this will
 indicate
> that the problem is with the Snapshot done before adding the staff.

 After executing (d-IncreaseGuard), the Denemo does not crash any more
 when inserting a staff.
>>>
>>> Well, I've gone over the snapshotting code and done some cleaning and
>>> re-coding, commenting and protected against a condition that shouldn't
>>> arise. This is now in git.
>>> If, with this new version inserting/deleting a staff from that score (I
>>> guess it is any score with lyrics) is still crashing it is going to be
>>> quite tricky to debug.
>>> If you *do* have the current git source code crashing under gdb you
>>> could create a breakpoint at line 1176 of select.c which is where the
>>> snapshot code ends (you do a Ctrl-C to suspend the program, issue
>>>
>>> b select.c:1176
>>>
>>> to insert the break and then the command
>>>
>>> c
>>>
>>> to continue the program).
>>>
>>> Then it should stop on that line when you try to add/delete a staff.
>>>
>>> If it does stop then issuing 
>>>
>>> call call_out_to_guile ("(d-Save \"/home/aschneider/JUNKNAME.denemo\")")
>>>
>>> at the gdb prompt will save the score under the name JUNKNAME.denemo and
>>> this may the hold a clue.
>>
>> Hmm, it seems not to reach that point. I did as you recommended, yet
>> after inserting a new staff Denemo crashes before it reaches the
>> breakpoint. Or did you mean I should do that after executing
>> (d-IncreaseGuard)?
> 
> Oops, I forgot that the package building script automatically strips
> binaries, so the executable did not contain debug informations. After
> building by hand executing the local denemo binary, I was able to save
> the file as recommended. I send it to you in a private mail.

I have now seen that the version with debug informations does not crash.
So it might have something to do with the optimisation?

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 05.02.2017 um 22:02 schrieb Andreas Schneider:
> Am 03.02.2017 um 17:47 schrieb Richard Shann:
>> On Thu, 2017-02-02 at 23:33 +0100, Andreas Schneider wrote:
>>> Am 01.02.2017 um 22:48 schrieb Richard Shann:
 yes, but it could be a bug in Denemo that happens not to be
>>> triggered. 
 Can you try executing
 (d-IncreaseGuard) in the Scheme window or CLI and then seeing if it
 crashes? d- IncreaseGaurd will turn off the undo, and this will
>>> indicate
 that the problem is with the Snapshot done before adding the staff.
>>>
>>> After executing (d-IncreaseGuard), the Denemo does not crash any more
>>> when inserting a staff.
>>
>> Well, I've gone over the snapshotting code and done some cleaning and
>> re-coding, commenting and protected against a condition that shouldn't
>> arise. This is now in git.
>> If, with this new version inserting/deleting a staff from that score (I
>> guess it is any score with lyrics) is still crashing it is going to be
>> quite tricky to debug.
>> If you *do* have the current git source code crashing under gdb you
>> could create a breakpoint at line 1176 of select.c which is where the
>> snapshot code ends (you do a Ctrl-C to suspend the program, issue
>>
>> b select.c:1176
>>
>> to insert the break and then the command
>>
>> c
>>
>> to continue the program).
>>
>> Then it should stop on that line when you try to add/delete a staff.
>>
>> If it does stop then issuing 
>>
>> call call_out_to_guile ("(d-Save \"/home/aschneider/JUNKNAME.denemo\")")
>>
>> at the gdb prompt will save the score under the name JUNKNAME.denemo and
>> this may the hold a clue.
> 
> Hmm, it seems not to reach that point. I did as you recommended, yet
> after inserting a new staff Denemo crashes before it reaches the
> breakpoint. Or did you mean I should do that after executing
> (d-IncreaseGuard)?

Oops, I forgot that the package building script automatically strips
binaries, so the executable did not contain debug informations. After
building by hand executing the local denemo binary, I was able to save
the file as recommended. I send it to you in a private mail.

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 03.02.2017 um 17:47 schrieb Richard Shann:
> On Thu, 2017-02-02 at 23:33 +0100, Andreas Schneider wrote:
>> Am 01.02.2017 um 22:48 schrieb Richard Shann:
>>> yes, but it could be a bug in Denemo that happens not to be
>> triggered. 
>>> Can you try executing
>>> (d-IncreaseGuard) in the Scheme window or CLI and then seeing if it
>>> crashes? d- IncreaseGaurd will turn off the undo, and this will
>> indicate
>>> that the problem is with the Snapshot done before adding the staff.
>>
>> After executing (d-IncreaseGuard), the Denemo does not crash any more
>> when inserting a staff.
> 
> Well, I've gone over the snapshotting code and done some cleaning and
> re-coding, commenting and protected against a condition that shouldn't
> arise. This is now in git.
> If, with this new version inserting/deleting a staff from that score (I
> guess it is any score with lyrics) is still crashing it is going to be
> quite tricky to debug.
> If you *do* have the current git source code crashing under gdb you
> could create a breakpoint at line 1176 of select.c which is where the
> snapshot code ends (you do a Ctrl-C to suspend the program, issue
> 
> b select.c:1176
> 
> to insert the break and then the command
> 
> c
> 
> to continue the program).
> 
> Then it should stop on that line when you try to add/delete a staff.
> 
> If it does stop then issuing 
> 
> call call_out_to_guile ("(d-Save \"/home/aschneider/JUNKNAME.denemo\")")
> 
> at the gdb prompt will save the score under the name JUNKNAME.denemo and
> this may the hold a clue.

Hmm, it seems not to reach that point. I did as you recommended, yet
after inserting a new staff Denemo crashes before it reaches the
breakpoint. Or did you mean I should do that after executing
(d-IncreaseGuard)?

Andreas
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from denemo...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/denemo 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffdb3e6700 (LWP 1898)]
[New Thread 0x7fffdabe5700 (LWP 1899)]
[New Thread 0x7fffda3e4700 (LWP 1900)]
[New Thread 0x7fffd9be3700 (LWP 1901)]
[New Thread 0x7fffd93e2700 (LWP 1902)]
[New Thread 0x7fffd8be1700 (LWP 1903)]
[New Thread 0x7fffd83e0700 (LWP 1904)]
[New Thread 0x7fffd72f6700 (LWP 1905)]
[New Thread 0x7fffd7275700 (LWP 1906)]
Denemo - MESSAGE : Loading preference file: /home/andreas/.denemo-2.0.21/denemorc
Denemo - MESSAGE : Audio driver is 'jack'
Denemo - MESSAGE : Initializing JACK audio backend
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackPosixSemaphore::Connect name = jack_sem.2000_default_denemo
Jack: JackPosixSemaphore::Connect sem_getvalue 0
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = denemo refnum = 2
Jack: JackClient::Activate
Jack: JackPosixThread::StartImp : create non RT thread
[New Thread 0x7fffd71e2700 (LWP 1907)]
Jack: JackPosixThread::ThreadHandler : start
Jack: JackClient::kBufferSizeCallback buffer_size = 1024
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 2
Jack: JackClient::kActivateClient name = denemo ref = 2 
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Jack: JackClient::ClientNotify ref = 2 name = denemo notify = 18
Denemo - MESSAGE : The default fluidsynth soundfont has been loaded
Jack: JackClient::PortRegister ref = 2 name = denemo:in_1 type = 32 bit float mono audio port_index = 5
Jack: JackClient::PortRegister ref = 2 name = denemo:out_1 type = 32 bit float mono audio port_index = 6
Jack: JackClient::PortRegister ref = 2 name = denemo:out_2 type = 32 bit float mono audio port_index = 7
Jack: JackClient::Connect src = denemo:out_1 dst = system:playback_1
Jack: JackClient::Connect src = denemo:out_2 dst = system:playback_2
[New Thread 0x7fffd6878700 (LWP 1908)]
[New Thread 0x7fffd5e64700 (LWP 1909)]
Denemo - MESSAGE : MIDI driver is 'portmidi'
Denemo - MESSAGE : Initializing PortMidi backend
Denemo - MESSAGE : Opening input device 'ALSA: Midi Through Port-0'
Denemo 

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Sun, 2015-09-20 at 18:57 +0200, Andreas Schneider wrote:
> I can reproduce a crash the following way:
> * Open the command centre.
> * Search for "Second".
> * Repeat the search several times. After the item "Open Repeat Section"
> (i.e. when searching again while that item is active) the program crashes.

I can't get this to happen on my current build, nor on a windows build
1.2.5 that I've been testing.
I have an idea it may be possible to get that if the set of commands
that you have is in some way scrambled (something like the file
denemoui.xml referring to non-existent commands, or Default.commands
having something bad in it)... I'm really not sure, but try to test on a
completely clean system. (Alternatively - or even additionally - the
output from gdb's where command would be interesting...)

Richard



> 
> Andreas
> 
> ___
> Denemo-devel mailing list
> Denemo-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/denemo-devel



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Here is the back trace:

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: Datei oder Verzeichnis nicht gefunden.
(gdb) where
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7591c888 in gtk_text_buffer_set_text ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#2  0x004629c1 in ?? ()
#3  0x75971e02 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#4  0x75971e93 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#5  0x759727c5 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#6  0x75972c2c in gtk_tree_selection_select_path ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#7  0x75972d11 in gtk_tree_selection_select_iter ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#8  0x7598a641 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#9  0x7598ad74 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#10 0x7404a245 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#11 0x7405bf6c in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#12 0x74064778 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#13 0x74064f2a in g_signal_emit_by_name ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#14 0x757edee1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#15 0x757f1d5e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#16 0x7404a245 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#17 0x7405be62 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#18 0x74064778 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#19 0x74064f2a in g_signal_emit_by_name ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#20 0x757ebf55 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#21 0x757f1630 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#22 0x7404ced0 in g_cclosure_marshal_VOID__STRINGv ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#23 0x7404a474 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#24 0x74064087 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#25 0x74064f2a in g_signal_emit_by_name ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#26 0x0045f0c7 in ?? ()
#27 0x7404a474 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#28 0x74064087 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#29 0x740649df in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#30 0x75789a3d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#31 0x75789a95 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#32 0x7404a474 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#33 0x74064087 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#34 0x740649df in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#35 0x75787a20 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#36 0x71e19dc0 in ffi_call_unix64 ()
   from /usr/lib/x86_64-linux-gnu/libffi.so.6
#37 0x71e19828 in ffi_call ()
   from /usr/lib/x86_64-linux-gnu/libffi.so.6
#38 0x7404aebc in g_cclosure_marshal_generic_va ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#39 0x7404a474 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#40 0x74064087 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#41 0x740649df in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#42 0x7582c1c1 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#43 0x7404d233 in g_cclosure_marshal_VOID__BOXEDv ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#44 0x7404a474 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#45 0x74064087 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#46 0x740649df in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#47 0x7582997e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#48 0x7582adcb in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#49 0x7582d610 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#50 0x75800ebb in gtk_event_controller_handle_event ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#51 0x7599c46d in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#52 0x7586f44e in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#53 0x7404a474 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#54 0x74063b30 

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Wed, 2015-05-27 at 20:45 +0200, Andreas Schneider wrote:
 Am 26.05.2015 um 09:15 schrieb Richard Shann:
  It would seem that this crash happens when clicking on a menu item 
  (I say this because I can see
  
  gtk_menu_shell_activate_item ()
  
  in the back trace) before Denemo's close routine gets called.
  
  If I'm right it would be very surprising if clicking on other menu items
  worked as there is nothing special about the File-Quit or File-Close
  items. 
  
  Some questions then:
  Is the crash reliable?
  Can other menu items be invoked successfully?
  Does it happen if quit is initiated via a shortcut?
  
  As I may not be able to respond quickly over the next couple of days,
  I'll mention a further avenue of investigation here:
  If a break is set on the close_project() function (by issuing 
  
  gdb break close_project
  
  at the gdb command prompt) does the program still crash on exit?
 
 On Monday the crash happened every time, but today we could not
 reproduce it.


It seems that Denemo's threading code was only safe (?) for the X11
backend, I don't know whether this is relevant to the latest Jessie
distro (apparently there are other backends now, perhaps Jesie uses one
of them)
a quote from the thread:
make the point that the advertised code on which the OP relied is for
the X11 backend only. It is not just that it won't work in win32: it
won't work in wayland, broadway or quartz either. 

I *think* I have updated Denemo in git so that it will work for all
backends, so it would be really great if you can test again.

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Wed, 2015-05-27 at 20:45 +0200, Andreas Schneider wrote:
 Am 26.05.2015 um 09:15 schrieb Richard Shann:
  It would seem that this crash happens when clicking on a menu item 
  (I say this because I can see
  
  gtk_menu_shell_activate_item ()
  
  in the back trace) before Denemo's close routine gets called.
  
  If I'm right it would be very surprising if clicking on other menu items
  worked as there is nothing special about the File-Quit or File-Close
  items. 
  
  Some questions then:
  Is the crash reliable?
  Can other menu items be invoked successfully?
  Does it happen if quit is initiated via a shortcut?
  
  As I may not be able to respond quickly over the next couple of days,
  I'll mention a further avenue of investigation here:
  If a break is set on the close_project() function (by issuing 
  
  gdb break close_project
  
  at the gdb command prompt) does the program still crash on exit?
 
 On Monday the crash happened every time, but today we could not
 reproduce it. Thus we could not do the tests you suggested. I do not
 understand that behaviour.

Well, we'll just have to wait and see if it ever turns up again - there
are all sorts of particular circumstances that can do this sort of thing
which do not survive a re-boot of the operating system.
I looked up Debian Jessie and discovered it is the new Debian stable - I
didn't realize that. I'll wait to upgrade until we have the new release
as I don't want to perturb things right now.
Thank you for your feedback.

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 26.05.2015 um 09:15 schrieb Richard Shann:
 It would seem that this crash happens when clicking on a menu item 
 (I say this because I can see
 
 gtk_menu_shell_activate_item ()
 
 in the back trace) before Denemo's close routine gets called.
 
 If I'm right it would be very surprising if clicking on other menu items
 worked as there is nothing special about the File-Quit or File-Close
 items. 
 
 Some questions then:
   Is the crash reliable?
   Can other menu items be invoked successfully?
   Does it happen if quit is initiated via a shortcut?
 
 As I may not be able to respond quickly over the next couple of days,
 I'll mention a further avenue of investigation here:
   If a break is set on the close_project() function (by issuing 
 
 gdb break close_project
 
 at the gdb command prompt) does the program still crash on exit?

On Monday the crash happened every time, but today we could not
reproduce it. Thus we could not do the tests you suggested. I do not
understand that behaviour.

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

It would seem that this crash happens when clicking on a menu item 
(I say this because I can see

gtk_menu_shell_activate_item ()

in the back trace) before Denemo's close routine gets called.

If I'm right it would be very surprising if clicking on other menu items
worked as there is nothing special about the File-Quit or File-Close
items. 

Some questions then:
Is the crash reliable?
Can other menu items be invoked successfully?
Does it happen if quit is initiated via a shortcut?

As I may not be able to respond quickly over the next couple of days,
I'll mention a further avenue of investigation here:
If a break is set on the close_project() function (by issuing 

gdb break close_project

at the gdb command prompt) does the program still crash on exit?

Richard

On Mon, 2015-05-25 at 22:03 +0200, Andreas Schneider wrote:
 Am 25.05.2015 um 19:02 schrieb Richard Shann:
  Is that with Debian Jessie? I have Release 7.8(wheezy) and though it
  will hang in a pthread thing on quitting sometimes I don't ever see a
  segmentation fault.
  Are you able to start it under gdb and get a back trace on the
  segmentation fault?
 
 Yes, it is with Jessie i386. Actually, it is on someone else's machine
 whom I recommended Denemo. He was willing to help and run gdb, here's
 the output he sent me:
 
 ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
 Denemo - MESSAGE : Closing project 0
 ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
 ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
 ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
 
 Program received signal SIGSEGV, Segmentation fault.
 0x080b9c8f in ?? ()
 (gdb) where
 #0  0x080b9c8f in ?? ()
 #1  0x080b9d03 in ?? ()
 #2  0xb6caf46c in g_cclosure_marshal_VOID__VOID ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #3  0xb6cad83b in g_closure_invoke ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #4  0xb6cbf855 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #5  0xb6cc7eda in g_signal_emit_valist ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #6  0xb6cc80d5 in g_signal_emit ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #7  0xb7202e67 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #8  0xb737ae2a in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #9  0xb6caf4c7 in g_cclosure_marshal_VOID__VOIDv ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #10 0xb6cac2e2 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #11 0xb6cada5f in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #12 0xb6cc77f9 in g_signal_emit_valist ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #13 0xb6cc80d5 in g_signal_emit ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #14 0xb749ed2d in gtk_widget_activate ()
from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #15 0xb7380fbd in gtk_menu_shell_activate_item ()
from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 ---Type return to continue, or q return to quit---
 #16 0xb738142c in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #17 0xb73740e9 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #18 0xb736449d in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #19 0xb6cac2e2 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #20 0xb6cada5f in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #21 0xb6cc7353 in g_signal_emit_valist ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #22 0xb6cc80d5 in g_signal_emit ()
from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
 #23 0xb749ffec in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #24 0xb7361952 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #25 0xb7363931 in gtk_main_do_event ()
from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #26 0xb70d72e8 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
 #27 0xb70feed7 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
 #28 0xb6bbbda4 in g_main_context_dispatch ()
from /lib/i386-linux-gnu/libglib-2.0.so.0
 #29 0xb6bbc0c9 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
 #30 0xb6bbc479 in g_main_loop_run () from
 /lib/i386-linux-gnu/libglib-2.0.so.0
 #31 0xb73629ae in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
 #32 0x080b7ffa in ?? ()
 #33 0xb7ebeded in ?? () from /usr/lib/libguile.so.17
 #34 0xb7f2750b in scm_c_catch () from /usr/lib/libguile.so.17
 #35 0xb7ebf327 in scm_i_with_continuation_barrier ()
from /usr/lib/libguile.so.17
 ---Type return to continue, or q return to quit---
 #36 0xb7ebf3c0 in scm_c_with_continuation_barrier ()
from /usr/lib/libguile.so.17
 #37 0xb7f260d0 in scm_i_with_guile_and_parent () from
 /usr/lib/libguile.so.17
 #38 0xb7f26112 in scm_with_guile () from /usr/lib/libguile.so.17
 #39 0x080579be in main ()
 
 Andreas
 
 ___
 Denemo-devel mailing list
 Denemo-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/denemo-devel



___

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Mon, 2015-05-25 at 12:08 +0200, Andreas Schneider wrote:
 Am 25.05.2015 um 11:52 schrieb Andreas Schneider:
  On a Debian Jessie with KDE, Denemo 1.2.2 crashes with Attempt to
  unlock mutex that was not locked even at the first launch (after the
  question whether to re-use old settings, which I answered no):
 
 Oh, by mistake (or rather some bug in the Debian script) I had compiled
 Denemo without portmidi. When compiling with portmidi, Denemo starts up,
 but crashes on quit.

Well,  of course, it should not have crashed in either case. But this is
the point of updates to the thread handling made since 1.2.2 so it will
only be interesting if it happens in the current 1.2.3 (it will be more
useful to provide a Debian package for that anyway in practical terms).

Richard


 
 Andreas
 
 ___
 Denemo-devel mailing list
 Denemo-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/denemo-devel



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 25.05.2015 um 11:52 schrieb Andreas Schneider:
 On a Debian Jessie with KDE, Denemo 1.2.2 crashes with Attempt to
 unlock mutex that was not locked even at the first launch (after the
 question whether to re-use old settings, which I answered no):

Oh, by mistake (or rather some bug in the Debian script) I had compiled
Denemo without portmidi. When compiling with portmidi, Denemo starts up,
but crashes on quit.

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Mon, 2015-05-25 at 16:59 +0200, Andreas Schneider wrote:
 Am 25.05.2015 um 12:22 schrieb Richard Shann:
  Well,  of course, it should not have crashed in either case. But this is
  the point of updates to the thread handling made since 1.2.2 so it will
  only be interesting if it happens in the current 1.2.3 (it will be more
  useful to provide a Debian package for that anyway in practical terms).
 
 I compiled the current git master. Both with and without portaudio
 compiled in Denemo did start up, but gave a segmentation fault on quit.

Is that with Debian Jessie? I have Release 7.8(wheezy) and though it
will hang in a pthread thing on quitting sometimes I don't ever see a
segmentation fault.
Are you able to start it under gdb and get a back trace on the
segmentation fault?

Richard



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 25.05.2015 um 12:22 schrieb Richard Shann:
 Well,  of course, it should not have crashed in either case. But this is
 the point of updates to the thread handling made since 1.2.2 so it will
 only be interesting if it happens in the current 1.2.3 (it will be more
 useful to provide a Debian package for that anyway in practical terms).

I compiled the current git master. Both with and without portaudio
compiled in Denemo did start up, but gave a segmentation fault on quit.

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Am 25.05.2015 um 19:02 schrieb Richard Shann:
 Is that with Debian Jessie? I have Release 7.8(wheezy) and though it
 will hang in a pthread thing on quitting sometimes I don't ever see a
 segmentation fault.
 Are you able to start it under gdb and get a back trace on the
 segmentation fault?

Yes, it is with Jessie i386. Actually, it is on someone else's machine
whom I recommended Denemo. He was willing to help and run gdb, here's
the output he sent me:

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
Denemo - MESSAGE : Closing project 0
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

Program received signal SIGSEGV, Segmentation fault.
0x080b9c8f in ?? ()
(gdb) where
#0  0x080b9c8f in ?? ()
#1  0x080b9d03 in ?? ()
#2  0xb6caf46c in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#3  0xb6cad83b in g_closure_invoke ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#4  0xb6cbf855 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#5  0xb6cc7eda in g_signal_emit_valist ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#6  0xb6cc80d5 in g_signal_emit ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#7  0xb7202e67 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#8  0xb737ae2a in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#9  0xb6caf4c7 in g_cclosure_marshal_VOID__VOIDv ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#10 0xb6cac2e2 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#11 0xb6cada5f in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#12 0xb6cc77f9 in g_signal_emit_valist ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#13 0xb6cc80d5 in g_signal_emit ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#14 0xb749ed2d in gtk_widget_activate ()
   from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#15 0xb7380fbd in gtk_menu_shell_activate_item ()
   from /usr/lib/i386-linux-gnu/libgtk-3.so.0
---Type return to continue, or q return to quit---
#16 0xb738142c in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#17 0xb73740e9 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#18 0xb736449d in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#19 0xb6cac2e2 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#20 0xb6cada5f in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#21 0xb6cc7353 in g_signal_emit_valist ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#22 0xb6cc80d5 in g_signal_emit ()
   from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#23 0xb749ffec in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#24 0xb7361952 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#25 0xb7363931 in gtk_main_do_event ()
   from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#26 0xb70d72e8 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#27 0xb70feed7 in ?? () from /usr/lib/i386-linux-gnu/libgdk-3.so.0
#28 0xb6bbbda4 in g_main_context_dispatch ()
   from /lib/i386-linux-gnu/libglib-2.0.so.0
#29 0xb6bbc0c9 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#30 0xb6bbc479 in g_main_loop_run () from
/lib/i386-linux-gnu/libglib-2.0.so.0
#31 0xb73629ae in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#32 0x080b7ffa in ?? ()
#33 0xb7ebeded in ?? () from /usr/lib/libguile.so.17
#34 0xb7f2750b in scm_c_catch () from /usr/lib/libguile.so.17
#35 0xb7ebf327 in scm_i_with_continuation_barrier ()
   from /usr/lib/libguile.so.17
---Type return to continue, or q return to quit---
#36 0xb7ebf3c0 in scm_c_with_continuation_barrier ()
   from /usr/lib/libguile.so.17
#37 0xb7f260d0 in scm_i_with_guile_and_parent () from
/usr/lib/libguile.so.17
#38 0xb7f26112 in scm_with_guile () from /usr/lib/libguile.so.17
#39 0x080579be in main ()

Andreas

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

I have put a fix for the bug I identified yesterday, but I don't think
it is your bug. Are you able to run denemo under gdb and report where it
crashes?
Richard
On Tue, 2012-10-02 at 22:22 +0200, Andreas Schneider wrote:
 Hi,
 
 on my installation, the current git version of Denemo crashes
 reproducably on doing the following:
 
 * in the menu, go to Edit  Customize commands, shortcuts  Manage
 command sets
 * click Load a standard command set
 * select Composer.shortcuts and click ok
 * Denemo crashes
 
 I am currently on the default command set. In fact, this was the first
 thing after I installed the git version (I had 0.9.6 installed before).
 I am using Debian testing (Wheezy). Can you reproduce this crash?
 
 Best regards
 
 Andreas
 
 ___
 Denemo-devel mailing list
 Denemo-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/denemo-devel



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Richard Shann]

On Tue, 2012-10-02 at 14:28 -0600, Josue Abarca wrote:
 
 I can confirm this crash.
 
 The last messages in the terminal:
 
 #-
 (denemo:21030): GLib-GObject-WARNING **: invalid cast from `EvView'
 to 
The Evince developers have come up with a fix which I have put into
Denemo git. I am not sure if this caused any crash, that would be the
other bug, now fixed. But the GLib-GObject warnings should be gone and
point and click in the PrintView window should show the hand cursor when
hovering over a note and a green patch should be drawn onto the note
which has been followed.
 
Please test.
Richard


___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] Denemo crash

[Andreas Schneider]

Hi,

Am 03.10.2012 13:52, schrieb Richard Shann:
 Thanks for that. I can see a problem with that code, which I have fixed
 and checked in to git.
 In fact,though it seems that this problem was triggered by the presence
 of an entry for a command that no longer exists. I have deleted that
 entry too.
 
  If you can re-build with that and re-test that would be great, thank
 you.

the crash does not occur any more, though I can't tell which of the two
(removing the non-present entry or fixing the code) did the job. Thank
you for the quick fix.

Andreas


 One curious thing, probably unimportant - the debugger complained about
 the debug information - a Dwarf opcode it didn't recognize. Either a bug
 in the tools, or some mis-match between versions.
 Let me know if there is more trouble.

___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] denemo crash with multiple keysignatures

[Richard Shann]

I have just
git checkout master
git pull
./autogen.sh
and the made. Everything seems to be working fine.
(gtk2 of course)
I guess you have some configuration thing messed up?

Richard


On Thu, 2011-12-01 at 11:07 -0600, Jeremiah Benham wrote:
 In master I am now getting a crash when I:
 place an initial keysig
 place notes
 place a keysig change
 
 bt gives me this:
 #19 0x0805fef2 in scorearea_configure_event (widget=0x85a1078, 
 event=0x8587ad8)
  at draw.c:77
  gui = 0x895b5b8
 
 I can recompile with --enable-debug if you need more.
 
 Jeremiah
 
 
 ___
 Denemo-devel mailing list
 Denemo-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/denemo-devel



___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel

Re: [Denemo-devel] denemo crash with multiple keysignatures

[Jeremiah Benham]

I pushed a change that fixes this.

Jeremiah

Sent from my Samsung smartphone on ATT

Richard Shann richard.sh...@virgin.net wrote:

hmm, I spoke to soon. I did make clean and then make
and now keysig change is doing some corruption all right.
Richard

On Thu, 2011-12-01 at 11:07 -0600, Jeremiah Benham wrote:
 In master I am now getting a crash when I:
 place an initial keysig
 place notes
 place a keysig change
 
 bt gives me this:
 #19 0x0805fef2 in scorearea_configure_event (widget=0x85a1078, 
 event=0x8587ad8)
  at draw.c:77
  gui = 0x895b5b8
 
 I can recompile with --enable-debug if you need more.
 
 Jeremiah
 
 
 ___
 Denemo-devel mailing list
 Denemo-devel@gnu.org
 https://lists.gnu.org/mailman/listinfo/denemo-devel


___
Denemo-devel mailing list
Denemo-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel