Firestorm
  1. Firestorm
  2. FIRE-5058

Uploading texture crashes Firestorm on Linux

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: Phoenix Firestorm 3.3.0, Phoenix Firestorm 4.0.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
    • SL Avatar Name:
      Timo Gufler
    • Reported In:
      Firestorm 3.3.0.24880 Maintenance Release

      Description

      How to reproduce:

      1. Start Firestorm and login
      2. Choose upload texture (Ctrl-U)
      3. The viewer shows the file dialog shortly and crashes without warning always

      End of Firestorm log file attached.

      1. debug_info.log
        19 kB
        Timo Gufler
      2. Firestorm.log
        3 kB
        Timo Gufler
      3. firestorm-gdb-bt.log
        4 kB
        Timo Gufler

        Issue Links

          Activity

          Hide
          Timo Gufler added a comment -

          Snapshot saving dialog crashes too when you try change directory. Fortunately, it allows you to type the path and save.

          Show
          Timo Gufler added a comment - Snapshot saving dialog crashes too when you try change directory. Fortunately, it allows you to type the path and save.
          Hide
          Timo Gufler added a comment -

          I ran Firestorm in gdb and got the backtrace which is attached now.

          Show
          Timo Gufler added a comment - I ran Firestorm in gdb and got the backtrace which is attached now.
          Hide
          Peace Howlett added a comment - - edited

          Having a similar problem, although I don't see any dialog, the viewer just vanishes. I think this problem is similar enough though to assume it's the same as you have a similar output mentioning 'handleViewerCrash: Last render pool type: 15', same as I have. After digging around I found this jira https://jira.secondlife.com/browse/VWR-28275, which has been closed, and linked to this issue https://jira.secondlife.com/browse/VWR-28441, Disabling VBO options and/or hardware skinning has no effect for me, it still crashes.

          Show
          Peace Howlett added a comment - - edited Having a similar problem, although I don't see any dialog, the viewer just vanishes. I think this problem is similar enough though to assume it's the same as you have a similar output mentioning 'handleViewerCrash: Last render pool type: 15', same as I have. After digging around I found this jira https://jira.secondlife.com/browse/VWR-28275 , which has been closed, and linked to this issue https://jira.secondlife.com/browse/VWR-28441 , Disabling VBO options and/or hardware skinning has no effect for me, it still crashes.
          Hide
          Timo Gufler added a comment -

          @Peace Just curious to ask, what operating system are you using and is it 32bit or 64bit? I'm on Arch Linux, which gets the latest libraries and software before many main stream distros. This can make some bugs appear earlier...

          Show
          Timo Gufler added a comment - @Peace Just curious to ask, what operating system are you using and is it 32bit or 64bit? I'm on Arch Linux, which gets the latest libraries and software before many main stream distros. This can make some bugs appear earlier...
          Hide
          Peace Howlett added a comment -

          I'm using Arch Linux 64-bit, I think I may have replied to you in the comments of the Secondlife packages in AUR?. What I have found out so far is this problem still occurs in the latest viewer built from source, it seems to be a GTK problem, although Phoenix viewer works as normal (in Arch 64). This bug seems to occur in all v3 32-bit viewers running on a 64-bit Arch system, the crash seems to occur around here : llwindow/llwindowsdl.cpp(1142) : beforeDialog: LLWindowSDL::beforeDialog()

          Like you said Arch doe's use the very latest libs, so maybe the problem is there, but Phoenix Viewer detects and displays the GTK dialog as normal.

          Show
          Peace Howlett added a comment - I'm using Arch Linux 64-bit, I think I may have replied to you in the comments of the Secondlife packages in AUR?. What I have found out so far is this problem still occurs in the latest viewer built from source, it seems to be a GTK problem, although Phoenix viewer works as normal (in Arch 64). This bug seems to occur in all v3 32-bit viewers running on a 64-bit Arch system, the crash seems to occur around here : llwindow/llwindowsdl.cpp(1142) : beforeDialog: LLWindowSDL::beforeDialog() Like you said Arch doe's use the very latest libs, so maybe the problem is there, but Phoenix Viewer detects and displays the GTK dialog as normal.
          Hide
          Peace Howlett added a comment - - edited

          Just an update about this particular bug.

          It was pointed out to me by the Secondlife package maintainer at the AUR (Arch user repositary), that lib32-libpng was the cause of this crash. The Arch version of libpng includes an apng patch (I'm unsure if other distro's include this or not). I built lib32-libpng (1.5.9) without this patch, installed it, and then compiled firestorm against it, which seems to have done the trick, since the dialog seems to be behaving, and working as normal now, hope this helps.

          Edited to add a link to the AUR package mentioned above : https://aur.archlinux.org/packages.php?ID=8093

          Show
          Peace Howlett added a comment - - edited Just an update about this particular bug. It was pointed out to me by the Secondlife package maintainer at the AUR (Arch user repositary), that lib32-libpng was the cause of this crash. The Arch version of libpng includes an apng patch (I'm unsure if other distro's include this or not). I built lib32-libpng (1.5.9) without this patch, installed it, and then compiled firestorm against it, which seems to have done the trick, since the dialog seems to be behaving, and working as normal now, hope this helps. Edited to add a link to the AUR package mentioned above : https://aur.archlinux.org/packages.php?ID=8093
          Hide
          Timo Gufler added a comment -

          Thanks for your study, Peace. What can be done next? Ask the lib32-libpng maintainer to reverse the patch? Make a work-around in Firestorm AUR package? Change the viewer code? Or something else?

          Show
          Timo Gufler added a comment - Thanks for your study, Peace. What can be done next? Ask the lib32-libpng maintainer to reverse the patch? Make a work-around in Firestorm AUR package? Change the viewer code? Or something else?
          Hide
          Peace Howlett added a comment -

          Not sure what should be done in this case since the apng patch is unofficial, Firestorm could be compiled against a newer libpng (1.5.9 atm), and the libs 'libpng15.so.15, libpng15.so.15.9.0' supplied, and placed into the viewers 'lib' folder (1.5.9 fixes some serious security bugs). Or the AUR Secondlife/firestorm package maintainers could have a script within the pkgbuild, to build lib32-libpng (1.5.1, without the patch), and copy those two libs above to the viewers lib folder, on install. I'm unsure if using 1.5.1 is safe though, since there are a few major security flaws with anything under 1.5.8, the supplied Secondlife builds are built against 1.5.1, which is what we will need with the prebuilt binaries. But the last idea I think may be the easiest, and we will still have our apng enabled lib32-libpng unntouched and installed on our systems.

          Show
          Peace Howlett added a comment - Not sure what should be done in this case since the apng patch is unofficial, Firestorm could be compiled against a newer libpng (1.5.9 atm), and the libs 'libpng15.so.15, libpng15.so.15.9.0' supplied, and placed into the viewers 'lib' folder (1.5.9 fixes some serious security bugs). Or the AUR Secondlife/firestorm package maintainers could have a script within the pkgbuild, to build lib32-libpng (1.5.1, without the patch), and copy those two libs above to the viewers lib folder, on install. I'm unsure if using 1.5.1 is safe though, since there are a few major security flaws with anything under 1.5.8, the supplied Secondlife builds are built against 1.5.1, which is what we will need with the prebuilt binaries. But the last idea I think may be the easiest, and we will still have our apng enabled lib32-libpng unntouched and installed on our systems.
          Hide
          Peace Howlett added a comment -

          The Secondlife package maintainer kindly added the workaround in the AUR.

          Show
          Peace Howlett added a comment - The Secondlife package maintainer kindly added the workaround in the AUR.
          Hide
          Timo Gufler added a comment -

          I updated SL viewer, copied the libpng* files from its lib directory to lib directory of Firestorm. As a result, FS doesn't crash anymore with the file dialog. Do you think, firestorm-bin AUR could be updated similar way as well?

          Show
          Timo Gufler added a comment - I updated SL viewer, copied the libpng* files from its lib directory to lib directory of Firestorm. As a result, FS doesn't crash anymore with the file dialog. Do you think, firestorm-bin AUR could be updated similar way as well?
          Hide
          Peace Howlett added a comment -

          I asked the Secondlife package maintainer to consider adding the workaround, which they kindly agreed to do. I'm sure the Firestorm-bin AUR maintainer would do the same if someone asked them nicely, they can refer to the Secondlife fixed PKGBUILD. I created a small patch (http://pastebin.com/qEDUqFwN) that I use when I build Firestorm from source, it basically downloads an updated libpng (1.5.9) with the libs included, then copys the libs to the lib folder.

          Show
          Peace Howlett added a comment - I asked the Secondlife package maintainer to consider adding the workaround, which they kindly agreed to do. I'm sure the Firestorm-bin AUR maintainer would do the same if someone asked them nicely, they can refer to the Secondlife fixed PKGBUILD. I created a small patch ( http://pastebin.com/qEDUqFwN ) that I use when I build Firestorm from source, it basically downloads an updated libpng (1.5.9) with the libs included, then copys the libs to the lib folder.
          Hide
          Timo Gufler added a comment -

          I added a comment to AUR. Let's see, what the maintainer will respond.

          Show
          Timo Gufler added a comment - I added a comment to AUR. Let's see, what the maintainer will respond.
          Hide
          Nicky added a comment -

          Even when I compile libpng with that patch, I cannot get FS to crash at all.

          This seems to be related to libpng+apng and the file chooser having to display preview thumbnails, too. I am not sure if previews instead of a list are another Arch addition, or if they are in stock gtk. At least in Gentoo I did not find a quick way to enable something like that.

          I am resolving this, as it is not a FS bug.

          Show
          Nicky added a comment - Even when I compile libpng with that patch, I cannot get FS to crash at all. This seems to be related to libpng+apng and the file chooser having to display preview thumbnails, too. I am not sure if previews instead of a list are another Arch addition, or if they are in stock gtk. At least in Gentoo I did not find a quick way to enable something like that. I am resolving this, as it is not a FS bug.
          Hide
          XenHat added a comment -

          @Peace Howlett: Thanks. This saved me today.

          Show
          XenHat added a comment - @Peace Howlett: Thanks. This saved me today.

            People

            • Assignee:
              Nicky
              Reporter:
              Timo Gufler
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: