Segmentation fault on preview (ctrl+p)

Bug #596253 reported by Jan Schlüter
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fractal Fr0st
Fix Released
Undecided
Unassigned

Bug Description

I am running Ubuntu 10.04 with fr0st 1.1. As I am also using ElectricSheep, I set it up as described in the comments on http://fr0st.wordpress.com/2010/05/22/installing-fr0st-in-ubuntu/ (i.e. downloaded and compiled FLAM3 version LNX-2.8b7.5M, but instead of installing, copied the .so files to fr0stlib/pyflam3/linux_so), but I don't think this should make a difference.

When I start with a clean environment (rm -rf ~/.fr0st ~/fr0st-*), start fr0st (./fr0st.py) and press ctrl+p, the preview window pops up and rendering starts. With a chance of 2:3, fr0st exists with a segmentation fault the moment the rendering progress bar reaches 100%.

As this probably doesn't help anybody fixing the bug, could you please tell me what further information I can provide? I am new to debugging on Linux and don't know where to start.

Revision history for this message
Vitor Bosshard (algorias) wrote :

Ok, do you get an error message of any kind, or does fr0st just crash? if it crashes, try running it from a terminal and see if it writes anything to stderr. Post any output you get here.

Other than this error, is fr0st rendering properly? do the thumbnails of each flame show up? can you render flames to disk? Did you do anything in fr0st before pressing ctrl-p?

Revision history for this message
Jan Schlüter (f0k) wrote :

- fr0st just closes. The only thing it writes to the terminal is "Segmentation fault".
- Other than that, it is rendering properly. Right now the preview renders correctly most of the times when I delete ~/.fr0st before starting fr0st. If I don't delete ~/.fr0st, it crashes most of the times, the same if I close and reopen the preview.
- The thumbnails are all okay.
- I tried rendering to disk (opened fr0st, pressed ctrl+r, clicked Render) and I get the same behavior. In 10 of 10 trials, fr0st closes and writes "Segmentation fault" to the terminal when the progress bar filled up (the last thing one can read in the status bar before it closes is "Rendering 1/1 (linear): 96.80 % Running density estimation"). No png file is written.
- I did not do anything before pressing ctrl+p or ctrl+r. I deleted ~/.fr0st so it would start with three sample flames, "linear" being the flame selected.

Is there anything I can do to obtain some information on where the segmentation fault occurred?

Revision history for this message
Vitor Bosshard (algorias) wrote :

I can't reproduce the error. What files do you have in the linux_so folder? In my case it's libflam3.a, .la, .so, .so.0 and .so.0.0.0 (This is what ends up in /usr/lib if you make install).

I suggest you make sure you have all those files (perhaps do a "sudo make install" and then move the files manually out of /usr/lib into your linux_so folder).

If that still doesn't work, you should try the 1.2 development version to see if it works for you (it's hosted right here on lp, use bazaar to get it). If you go that route, you need to drop the -r 5 argument from the svn co call of the script, so it fetches the latest flam3 version.

Revision history for this message
Jan Schlüter (f0k) wrote :

I only had the three .so files in the linux_so folder. I copied the other files as well, but it didn't change anything (I guess they are not needed).
Do you have electricsheep (and with it Ubuntu's flam3 package) installed as well? I don't know if this makes a difference. From what I understand, it shouldn't, because fr0st only uses the .so files I copied to its linux_so directory.

I downloaded, compiled and copied the latest flam3 libaries (flam3 svn revision 13) to the linux_so folder: no difference. I downloaded the latest fr0st version from bazaar and put the latest flam3 libraries in the corresponding linux_so folder: no difference. Still the preview crashes most of the time, the rendering crashes every time.

I don't think it will be easy to reproduce the error, I think a better way would be trying to localize it here. I just don't know how to do that. Maybe gdb can help?

Revision history for this message
Vitor Bosshard (algorias) wrote :

You're correct, having electric sheep installed shouldn't make a difference. As you said, with so little info it's very hard to find out anything. If you have tried using gdb let me know the results, ok?

Revision history for this message
Jan Schlüter (f0k) wrote :

The problem is fixed in fr0st 1.2 (using flam3 svn revision 34), good job!

Changed in fr0st:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.