#7 Fedora 12 problem

open-duplicate
Jens Göpfert
Interface (14)
5
2011-05-28
2010-01-26
TMP-StephenH
No

I installed first 1.3.2 and tried to import a folder full of pictures from a trip to work with. The program crashed.

When I start the program from the command line, this is the message that is
displayed:

[stephenh@emerald ~]$ photofilmstrip
/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn("wxPython/wxWidgets release number mismatch")

When it crashes, this is the message:

Gdk-ERROR **: The program 'python' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 1692127 error_code 11 request_code 53 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
aborting...

I saw that there was an upgrade, so I installed 1.3.3, but the same message on starting from command line remains. I have not yet tried to import the same group of photos with 1.3.3 but since the same error message remains on startup, it is likely the same result would happen. I have filed a bug report on Feodra's bugzilla page. The link for that is: https://bugzilla.redhat.com/show_bug.cgi?id=558095 . I have attached the backtrace from 1.3.2 that the Automatic Bug Reporting Tool generated from the crash.

/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450:
UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn("wxPython/wxWidgets release number mismatch")

Discussion

  • TMP-StephenH
    TMP-StephenH
    2010-01-26

    backtrace of 1.3.2 failure

     
    Attachments
  • TMP-StephenH
    TMP-StephenH
    2010-01-26

    I received the advice to upgrade wxPython from the testing repository. It cleared the startup message about the release number mismatch.

    However the program still aborted with the following message:

    Gdk-ERROR **: The program 'python' received an X Window System error.
    This probably reflects a bug in the program.
    The error was 'BadAlloc (insufficient resources for operation)'.
    (Details: serial 1689392 error_code 11 request_code 53 minor_code 0)
    (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error() function.)
    aborting...
    Aborted (core dumped)

    The program still aborts when I try to import a folder of pictures through selecting the button to import photos, navigating to the folder with the pictures and selecting all (CTRL-A) the photos in the folder and then clicking the Open button. the process of importing starts, but the program does not complete the importing of the files.

    Is it possible that I need to change permission on some file/folder somewhere to allow this to complete successfully?

     
  • Jens Göpfert
    Jens Göpfert
    2010-01-26

    This error seems to occur depply inside wxWidgets/wxPython, but i will try to figure it out.
    How many pictures are in that folder you try to add into PhotoFilmStrip? Have u tried adding just a few pictures for the beginning (maybe 5 to 7). The backtrace file sais something about "insufficent resources". Maybe your system runs out of ressources?
    Loading a bunch of pictures into memory consumes a lot of resources. PhotoFilmStrip does not load all the pictures into memory. Only a low resolution version of each picture. But maybe even this consumes to much memory. How many RAM is installed in your system?

     
  • TMP-StephenH
    TMP-StephenH
    2010-01-26

    The system is an AMD dual-core processor based 64 bit system with 4 GB RAM, so memory should not be an issue here.

    The number of pictures I was attempting to import was 202. The import process seemed to run okay for a while and pictures were showing up in the window. I am not sure at what point the failure occurs since I had not been watching the screen closely.

    I had also tried installing the Windows version (1.3.2) using Crossover Office (WINE). It also failed to load the same pictures, but I did not look at error messages there since I only tried it once.

     
  • TMP-StephenH
    TMP-StephenH
    2010-01-26

    I tried loading pictures in groups. Loaded 157 okay
    loaded group of 10: okay
    loaded group of 10: okay
    loaded group of 10: okay
    loaded final group: crash

    Please see the redhat bugzilla report (558095) for additional discussion. I posted the link to this site there. It may be related to Fedora 12 changing GTK versions. https://bugzilla.redhat.com/show_bug.cgi?id=558095

     
  • Jens Göpfert
    Jens Göpfert
    2010-01-26

    i tried on my system too and i can confirm this problem. After 200 pics PhotoFilmStrip crashed with the error you reported. i am using Ubuntu Karmic on a 32bit machine. I tried the Windows version of PhotoFilmStrip and i had no error after 500 pics.

     
  • TMP-StephenH
    TMP-StephenH
    2010-01-26

    Since I tried it using Crossover Office and not directly from a Windows installation, that may explain the difference in results between your test and mine.

    I hope that it will be something easy to fix. Now that you have confirmed it on Ubuntu, it is certain that it is not just a Fedora issue. I will post this information on the bugzilla page so the developers there know as well.

    Respectfully,

    Stephen

     
  • TMP-StephenH
    TMP-StephenH
    2011-01-29

    PhotoFilmstrip 1.4.0 still has a problem with >200 photos, abending without any warning message.

     
  • Jens Göpfert
    Jens Göpfert
    2011-05-28

    • assigned_to: nobody --> hammerwerfer
    • labels: --> Interface
    • status: open --> open-duplicate
     
  • Jens Göpfert
    Jens Göpfert
    2011-05-28

    This bug is probably fixed with release 1.4.3