Description of problem: I wanted to view the website of my network printer (Lexmark X544). Version-Release number of selected component: seamonkey-2.53.14-3.fc37 Additional info: reporter: libreport-2.17.4 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-seamonkey-faf85300af704ce6acb6e555ca13c2f3.scope cmdline: /usr/bin/seamonkey crash_function: nsProfileLock::FatalSignalHandler dso_list: /usr/lib64/seamonkey/seamonkey seamonkey-2.53.14-3.fc37.x86_64 (Fedora Project) 1672920863 executable: /usr/lib64/seamonkey/seamonkey journald_cursor: s=538cbdda8b724e66ba6b578489ca4d83;i=154fe7;b=fc14a2d5005a4647a069befed734cc94;m=1d460dbc2;t=5f18539307a48;x=b72da5d29964c4f5 kernel: 6.0.16-300.fc37.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000
Created attachment 1935948 [details] File: backtrace
Created attachment 1935949 [details] File: core_backtrace
Created attachment 1935950 [details] File: cpuinfo
Created attachment 1935951 [details] File: environ
Created attachment 1935952 [details] File: limits
Created attachment 1935953 [details] File: maps
Created attachment 1935954 [details] File: mountinfo
Created attachment 1935955 [details] File: open_fds
Created attachment 1935956 [details] File: proc_pid_status
How reliable is this bug reproduced for you? (Ie. each time vs. sometimes vs. once)
Hi, it happens every time I try to access the printer page. It did work before, the only thing I can remember that changed was an update from Fedora 35 to Fedora 37. The update worked without any troubles. Regards Wolfgang Reh
Thanks for the answer. Could you try to reproduce the crash with the printer page "copied" to your local disk? I mean access the printer page by the previous, worked SM version (or some another browser), then "Save Page As" to the local disk, then try to open "file:///path_where_saved". If it also results in a crash, then send the whole saved stuff to me so I can reproduce it myself. This will greatly help in fixing this bug, since the main problem for developers is the inability to reproduce the bug themselves.
Created attachment 1937162 [details] Saved Webpage (complete) as saved with Falkon Hi, if I save the webpage (complete) with Falkon (which opens the page without troubles ... as before Seamonkey did) I cannot open the saved page as Seamonky crashes again. I attached the Complete webpage as tar.gz. Regards Wolfgang Reh
Thanks. Does not crash for me, at least under CentOS 7. :( Since you already have a test case (the crash on the saved page), could you reproduce it on a safe mode (ie. start from cmdline as "seamonkey -safe-mode" ) and/or on a clean profile (IOW, mv ~/.mozilla ~/.mozilla-SAVED, then start SM etc.)? This could help to figure out if the crash is related to installed SM extensions or something in your usual SM profile. If it crashes on a clean profile, could you also check (on such a "testing" profile) whether it crahes on the generic Fedora/CentOS build (https://buc.fedorapeople.org/seamonkey/download/seamonkey-2.53.14-3.tar.xz) and on the official upstream build (http://archive.mozilla.org/pub/seamonkey/releases/2.53.14/linux-x86_64/de/seamonkey-2.53.14.de.linux-x86_64.tar.bz2). Both are build under CentOS-7, that way we can check if the crash is related to particular compiler, build and run environment etc. For now, it is clean that the crash is triggered by an extra "meta" tag in langbar.html (note line 3 in the saved ./Lexmark_X544_files/langbar.html, and #13 of Thread 1 in the initial backtrace attached). What happens if you open this "langbar.html" directly (without any other activity in the browser session)?
Hi, I've tried all the variants you gave in your last comment: 1 - Start with "seamonkey -safe-mode": This crashes like before. 2 - Moved the profile and started with a blank profile: This crashes like before. 3 - Started generic Fedora/CentOS build: Downloaded from https://buc.fedorapeople.org/seamonkey/download/seamonkey-2.53.14-3.tar.xz Unpacked the archive and started it from the command line as seamonkey This works! 4 - Started official upstream build: Downloaded from http://archive.mozilla.org/pub/seamonkey/releases/2.53.14/linux-x86_64/de/seamonkey-2.53.14.de.linux-x86_64.tar.bz2 Unpacked the archive and started it from the command line as seamonkey This works! 5 - I added a test with the "official upstream build" and my unchanged profile: First I saved my profile ;) Started the "official upstream build" and saw that my skin and extensions where there. This works! So for me it seams as if it is a problem of the current version in the official Fedora-Repo. Will there be a "new" version released soon? I would prefer to use the version from the Fedora-Repo. Regards Wolfgang Reh
Thanks a lot! It seems to me that the problem is Fedora-37 uses new system ICU library version 71.1 . Fedora-35's one was 69.1, and the bundled "generic" and "upstream" ones are 63.1 . The Firefox package (we're orienting on) has long since abandoned the system ICU library at all in favor of the bundled one (provided by the ordinary program source). Apparently we should follow this behavior since now, and use the bundled ICU library, provided by the SeaMonkey upstream source. New 2.53.15 version should appear soon, and I'll build it with the bundled ICU. For now, you can use the generic Fedora/CentOS one for that printer page.
FEDORA-2023-dfeb282345 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-dfeb282345
Could you please test new 2.53.15 build https://kojipkgs.fedoraproject.org//packages/seamonkey/2.53.15/1.fc37/x86_64/seamonkey-2.53.15-1.fc37.x86_64.rpm (from https://koji.fedoraproject.org/koji/buildinfo?buildID=2135296) ?
FEDORA-2023-dfeb282345 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-dfeb282345` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-dfeb282345 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Hi, I tried the rpm from the link in comment #18 ... but this version still crashes. Regards, Wolfgang Reh
Thanks. Well, then I would like to ask you to test one more package (2.53.15-1.1) from the special scratch build: https://kojipkgs.fedoraproject.org//work/tasks/8684/96628684/seamonkey-2.53.15-1.1.fc37.x86_64.rpm It is built, like the upstream and Fedora generic versions, with all the bundled libraries (instead of system ones). Such a test will help determine if the problem lies in the system libraries, or if it is a compilation environment issue.
Hi, sorry for the bad news ... but this version also crashes. Currently only the two version mentioned in Comment #14 and #15 work. Regards, Wolfgang Reh
Thanks for the tests. The results mean that the problem is not in the new F37's system libraries. In comment #11, you mentioned that the previously used Fedora-35 system did not have this problem. Could you pls try to test the old, f35's package: https://kojipkgs.fedoraproject.org//packages/seamonkey/2.53.14/3.fc35/x86_64/seamonkey-2.53.14-3.fc35.x86_64.rpm under your current Fedora 37? (IOW, either install it as "rpm -U --force .....", or unpack by rpm2cpio and use /usr/lib64/seamonkey data the same way as for upstream and generic build). If it will work OK, pls try also F36's one: https://kojipkgs.fedoraproject.org//packages/seamonkey/2.53.14/3.fc36/x86_64/seamonkey-2.53.14-3.fc36.x86_64.rpm F35's one was build by clang-13 compiler, F36's -- by clang-14, and F37 has clang-15. These tests can help determine if it is a compiler-specific issue (or some other build environment issue).
FEDORA-2023-dfeb282345 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Reopen, since the problem still persists.
Hi again, I've tried both versions and both of them crash :(. Obviously it's some problem with the environment in Fedora 37. I definitely had the printer page working in Fedora 35 (I skipped Fedora 36). Regards, Wolfgang Reh
Wolfgang, Could you please re-run the test with the f35's one? I finally managed to get to rawhide-test.fedorainfracloud.org machine and repeat all the tests with the tarball provided by you. The same results (ie. upstream and generic are OK, others failed), except F35 -- package https://kojipkgs.fedoraproject.org//packages/seamonkey/2.53.14/3.fc35/x86_64/seamonkey-2.53.14-3.fc35.x86_64.rpm does NOT crash! I'm testing at a remote VM using Xvfb, so I don't have access to the actual screen image. I can only state whether the program crashed or not. Therefore, please check the f35 package again (including on your real printer). Note -- to install "seamonkey-2.53.14-3.fc35" under F37 environment, you need to install old libjxl, libvpx and libdav1d packages (since F37 already have new ones). You can get it from: https://kojipkgs.fedoraproject.org//packages/jpegxl/0.6.1/6.fc35/x86_64/libjxl-0.6.1-6.fc35.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/libvpx/1.10.0/2.fc35/x86_64/libvpx-1.10.0-2.fc35.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/dav1d/0.9.2/1.fc35/x86_64/libdav1d-0.9.2-1.fc35.x86_64.rpm and then install as "rpm -i --force ......" (so you will have two instances simultaneously). So for now, the reason which triggered the issue is "Clang compiler since the version of 14". The last package without the issue is 2.53.11-1.fc36 (compiled by clang13), the first package affected is 2.53.11.1-2.fc36 (compiled by clang14).
Hi, I do have troubles to test the version seamonkey-2.53.14-3.fc35.x86_64.rpm. I did install the libraries you told, but I can't start seamonkey (extracted via rpm2cpio) because XPCOMGlueLoad error for file /home/Wolfgang/Downloads/smtest/usr/lib64/seamonkey/libxul.so: libicui18n.so.69: cannot open shared object file: No such file or directory Couldn't load XPCOM. I then tried to install the given seamonkey rpm with rpm -i --force ... (although I don't want to do that to not damage the existing installation) but this complains with > rpm -i --force seamonkey-2.53.14-3.fc35.x86_64.rpm Fehler: Fehlgeschlagene Abhängigkeiten: libicudata.so.69()(64bit) wird benötigt von seamonkey-2.53.14-3.fc35.x86_64 libicui18n.so.69()(64bit) wird benötigt von seamonkey-2.53.14-3.fc35.x86_64 libicuuc.so.69()(64bit) wird benötigt von seamonkey-2.53.14-3.fc35.x86_64 complaining about missing dependencies (sorry for the German text). Do you have an idea how I can run the test? Regards, Wolfgang Reh
Just install "libicu69" package first. Note, you can "rpm -U --force ..." for f35's seamonkey package to avoid rpm2cpio (if any). Note "-U"/update, not "-i"/install for seamonkey package. The "-i" is suitable for install (in "parallel") of three old f35 depended packages mentioned before.
Hi, ok, after also installing libicu69-69.1-1.fc37.x86_64.rpm seamonkey-2.53.14-3.fc35.x86_64.rpm starts ... and this Version CAN load the printer page! I've tried it directly with the printer (using http://<printer-IP>) and it works. Some change AFTER the version obviously broke something :o). Regards, Wolfgang Reh PS: Sorry for not directly thinking of "just install libicu69".
Upstream bug https://bugzilla.mozilla.org/show_bug.cgi?id=1604307 fixes the issue. It seems that things like "memcpy (somewhere, NULL, 0);" was allowed up to clang 13 (note length==0), but no more allowed since clang 14. Probably some more optimized/inlined memcpy() etc. Wolfgang, Could you finally (I hope :) ) test the fixed package (2.53.15-1.2) for f37: https://kojipkgs.fedoraproject.org//work/tasks/6661/96986661/seamonkey-2.53.15-1.2.fc37.x86_64.rpm against the real printer? It no more crashes for me anyway in tests with the tarball provided here.
Hi, you are right, this version works! I tested it against the real printer without any problem. If this version is distributed via the updates everything is fine again ... great. Regards, Wolfgang Reh
Fine! Thank you very much for your cooperation, especially for quickly providing a convenient and reliable test! You can use 2.53.15-1.2 for yourself for now, after the next update it will be replaced by the official release. I do not plan to make a new release just because of this error, since the problem is still not widespread. Moreover, a new 2.53.16 should appear soon, already with these changes.
FEDORA-2023-2212bff784 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2212bff784
FEDORA-2023-c85047d868 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c85047d868
FEDORA-2023-a6f685801e has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a6f685801e
FEDORA-2023-a6f685801e has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-a6f685801e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a6f685801e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-c85047d868 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c85047d868` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c85047d868 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-c85047d868 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-a6f685801e has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.