Created attachment 364365 [details]
File: backtrace

Thank you for taking the time to report this bug report.

It looks like a g_assert selftest failed somewhere inside /usr/lib64/libgtk-x11-2.0.so.0 whilst running solfege.  I believe that more precise information on the failure is being sent to "stderr", but that information didn't make it into this report.  If you run the program by hand from a terminal, does more error information show up on the terminal?

In addition, unfortunately, the stack trace is not very useful in determining the cause of the crash, because there is not a symbolic stack trace. In order to get a symbolic stack trace, the appropriate debuginfo packages need to be installed. In order to accomplish this, you can run the command: 

    debuginfo-install gtk2

Please see http://fedoraproject.org/wiki/StackTraces for more information about stack traces. 

(I'm reassigning this bug report's component from "python" to "solfege" in the hope that this is a known issue)

Thank you for such a detailed response! ;=)

Well, it was ABRT that generated this report. I'll install the debuginfo packages to see if I can attach a better stack trace next time.

Here's the error output and the steps it took to reproduce

1. Open solfege from commandlime (same result of not from commandline)
1.1 I get an error message that says: 

No module named _solfege_c_midi

You should configure sound from the preferences window, and try to use an external midi player. Or try to recompile the program and check for error messages to see why the module is not built.

2. Go to File>Preferences>Sound Setup
3. Choose "Use external midi player"
4. Click "Test" button.
5. Close the window
6. Now, on the welcome message, click the "Prev" link and it crashes.

ABRT detects this crash as a Python crash.

Here's the output:

[renich@introdesk ~]$ solfege 
Solfege will use fakesynth
info: ignoring duplicate tone: (NoteOnEvent, pitch:48, vel:100, time:(Rat 0/1))
info: not stopping, not playing now: (NoteOffEvent, pitch:48, vel:100, time:(Rat 1/4))
info: ignoring duplicate tone: (NoteOnEvent, pitch:52, vel:100, time:(Rat 1/4))
info: not stopping, not playing now: (NoteOffEvent, pitch:52, vel:100, time:(Rat 1/2))
info: ignoring duplicate tone: (NoteOnEvent, pitch:55, vel:100, time:(Rat 1/2))
info: not stopping, not playing now: (NoteOffEvent, pitch:55, vel:100, time:(Rat 5/8))
Playing /tmp/tmp7AsgGm.mid
MIDI file: /tmp/tmp7AsgGm.mid
Format: 1  Tracks: 1  Divisions: 96
Playing time: ~5 seconds
Notes cut: 0
Notes lost totally: 0
/usr/share/solfege/src/mainwin.py:938: GtkWarning: gtktextview.c:4567: somehow some text lines were modified or scrolling occurred since the last validation of lines on the screen - may be a text widget bug.
  gtk.main()

**
Gtk:ERROR:gtktextview.c:4568:gtk_text_view_paint: code should not be reached
/usr/bin/solfege: line 13:  4101 Aborted                 (core dumped) $solfegebin
/usr/bin/solfege: line 17: kill: (4100) - No such process

Thanks for the extra info; looks like something's going badly wrong inside the GtkTextView code.  Having a backtrace with the extra debuginfo would help track things down.

I'm not familiar with solfege.  Looks like either solfege is doing something unusual with the GtkTextView widget, or there's a bug in pygtk's wrapper for that widget, or there's something I'm not thinking of.  Hope this is helpful.

Ok, abrt did it:
https://bugzilla.redhat.com/show_bug.cgi?id=528619

It posted it there...

*** Bug 528619 has been marked as a duplicate of this bug. ***

Attachment 364550 [details] has the more detailed backtrace.

It shows that the
  if (!text_view->onscreen_validated)
    {
      g_warning (G_STRLOC ": somehow some text lines were modified or scrolling occurred since the last validation of lines on the screen - may be a text widget bug.");
      g_assert_not_reached ();
    }
clause within gtk_text_view_paint is being executed.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I can easily reproduce the issue, but I I don't have a solution yet. The same issue was reported for Ubuntu, but also without a solution yet.

Upstream is currently working on a new major release with a polished GUI which doesn't seem to have this kind of issue.

*** Bug 568212 has been marked as a duplicate of this bug. ***

(In reply to comment #7)
> Attachment 364550 [details] has the more detailed backtrace.
> 
> It shows that the
>   if (!text_view->onscreen_validated)
>     {
>       g_warning (G_STRLOC ": somehow some text lines were modified or scrolling
> occurred since the last validation of lines on the screen - may be a text
> widget bug.");
>       g_assert_not_reached ();
>     }
> clause within gtk_text_view_paint is being executed.    

Dave, do you have any idea how the problem could be tracked down? In general, if the interpreter itselfs crashs (or aborts caused by an exception in the native code), I certainly tend to say that it is a bug in the native code. Even if there would be something wrong in solfege's python code, the interpreter should in the worst case generate a python exception which could be handled by solfege.

Additionally I've asked the author and he told me that this problem will not be addressed from his side since this code will go away in the new major release (unstable releases available).

So seeing the problem just from solfege's side, I think I'll package the development version soon. I've already built and tested it a little bit and it looks quite stable so far.

Do you think it would be necessary to address the python/python gtk binding problem itself any further?

Christian: I've done quite a bit of work in F13, adding hooks to python-debuginfo to make it easier to see what's going on in Python code (https://fedoraproject.org/wiki/Features/EasierPythonDebugging ).

However, I took a look at the backtraces and I don't think that the Python side of things is at fault; I see a pure C traceback all the way from g_main_loop_run upwards.  So right now I think this is a bug in GtkTextView (I could well be wrong, though).

I've taken the liberty of CCing mclasen; Matthias, any ideas what's wrong here?

(In reply to comment #12)
> However, I took a look at the backtraces and I don't think that the Python side
> of things is at fault; I see a pure C traceback all the way from
> g_main_loop_run upwards.  So right now I think this is a bug in GtkTextView (I
> could well be wrong, though).
 
> I've taken the liberty of CCing mclasen; Matthias, any ideas what's wrong here?    

*ping* Matthias - do you have an idea what could be wrong here? Unfortunately solfege's upstream is not interested in fixing bugs in the old, stable version since the problematic code was completely removed in the new UI in their development version.

It would be great if you could probably give a hint! Thank you very much in advance.

No, I don't

solfege-3.16.0-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/solfege-3.16.0-1.fc13

solfege-3.16.0-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/solfege-3.16.0-1.fc12

Unfortunately I could not really solve the issue itself, but upstream has just released a new major release which does not contain the problematic code anymore.

Once the update hits updates-testing, it would be great if you could try out the new release and give some feedback in bodhi. Thanks!

Sure thing! I0'll check it out and tell you what happened.

It seems to work fine; good job ;)

solfege-3.16.0-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update solfege'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/solfege-3.16.0-1.fc13

solfege-3.16.0-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update solfege'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/solfege-3.16.0-1.fc12

solfege-3.16.0-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

solfege-3.16.0-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.