Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1688085 - [abrt] xsane: __memmove_sse2_unaligned_erms(): xsane killed by SIGSEGV
Summary: [abrt] xsane: __memmove_sse2_unaligned_erms(): xsane killed by SIGSEGV
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: xsane
Version: 29
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
URL: https://retrace.fedoraproject.org/faf...
Whiteboard: abrt_hash:196394fe7ffe0830f7fb140b44a...
: 1595682 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-13 05:32 UTC by Steve
Modified: 2019-03-16 18:02 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
File: backtrace (deleted)
2019-03-13 05:32 UTC, Steve
no flags Details
File: cgroup (deleted)
2019-03-13 05:32 UTC, Steve
no flags Details
File: core_backtrace (deleted)
2019-03-13 05:32 UTC, Steve
no flags Details
File: cpuinfo (deleted)
2019-03-13 05:32 UTC, Steve
no flags Details
File: dso_list (deleted)
2019-03-13 05:32 UTC, Steve
no flags Details
File: environ (deleted)
2019-03-13 05:33 UTC, Steve
no flags Details
File: exploitable (deleted)
2019-03-13 05:33 UTC, Steve
no flags Details
File: limits (deleted)
2019-03-13 05:33 UTC, Steve
no flags Details
File: maps (deleted)
2019-03-13 05:33 UTC, Steve
no flags Details
File: open_fds (deleted)
2019-03-13 05:33 UTC, Steve
no flags Details
File: proc_pid_status (deleted)
2019-03-13 05:33 UTC, Steve
no flags Details
Output of gdb > bt full (deleted)
2019-03-15 09:27 UTC, Steve
no flags Details

Description Steve 2019-03-13 05:32:51 UTC
Description of problem:
- Started scanning at 4800dpi
- Was gone for a coffee
- By returning, XSane has crashed

Version-Release number of selected component:
xsane-0.999-29.fc29

Additional info:
reporter:       libreport-2.10.0
backtrace_rating: 4
cmdline:        xsane
crash_function: __memmove_sse2_unaligned_erms
executable:     /usr/bin/xsane
journald_cursor: s=deaa87c5231d409baee22892d13e899f;i=34226;b=6d3bf30f62994d2092c210d4ab63be99;m=1bd73df1;t=583e4fd51c25a;x=3809b321d5189c04
kernel:         4.20.14-200.fc29.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 __memmove_sse2_unaligned_erms at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:460
 #1 xsane_viewer_read_image at ../../src/xsane-viewer.c:2547
 #2 xsane_viewer_new at ../../src/xsane-viewer.c:3121
 #3 xsane_scan_done at ../../src/xsane-scan.c:1226
 #4 xsane_read_image_data at ../../src/xsane-scan.c:551
 #5 xsane_start_scan at ../../src/xsane-scan.c:1869
 #6 xsane_scan_dialog at ../../src/xsane-scan.c:2169
 #11 gtk_real_button_released at gtkbutton.c:1712
 #16 gtk_button_button_release at gtkbutton.c:1604
 #18 _gtk_marshal_BOOLEAN__BOXED at gtkmarshalers.c:84

Potential duplicate: bug 1595682

Comment 1 Steve 2019-03-13 05:32:54 UTC
Created attachment 1543494 [details]
File: backtrace

Comment 2 Steve 2019-03-13 05:32:55 UTC
Created attachment 1543495 [details]
File: cgroup

Comment 3 Steve 2019-03-13 05:32:56 UTC
Created attachment 1543496 [details]
File: core_backtrace

Comment 4 Steve 2019-03-13 05:32:57 UTC
Created attachment 1543497 [details]
File: cpuinfo

Comment 5 Steve 2019-03-13 05:32:58 UTC
Created attachment 1543498 [details]
File: dso_list

Comment 6 Steve 2019-03-13 05:33:00 UTC
Created attachment 1543499 [details]
File: environ

Comment 7 Steve 2019-03-13 05:33:01 UTC
Created attachment 1543500 [details]
File: exploitable

Comment 8 Steve 2019-03-13 05:33:02 UTC
Created attachment 1543501 [details]
File: limits

Comment 9 Steve 2019-03-13 05:33:04 UTC
Created attachment 1543502 [details]
File: maps

Comment 10 Steve 2019-03-13 05:33:05 UTC
Created attachment 1543503 [details]
File: open_fds

Comment 11 Steve 2019-03-13 05:33:06 UTC
Created attachment 1543504 [details]
File: proc_pid_status

Comment 12 Zdenek Dohnal 2019-03-13 11:33:50 UTC
Hi Steve,

thank you for reporting the issue! Unfortunately, I do not have a scanner with 4800dpi support, so I'm not able to reproduce, but Tristan made a good point in previous report - the program falls when it is trying to create named file. I'll see what I can do.

Comment 13 Zdenek Dohnal 2019-03-13 11:34:03 UTC
*** Bug 1595682 has been marked as a duplicate of this bug. ***

Comment 14 Zdenek Dohnal 2019-03-13 14:51:18 UTC
It seems window widget is not big enough to store row of 4800dpi... I would like to confirm my theory - would you mind trying this scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=33457353 ?

Comment 15 Steve 2019-03-13 17:40:19 UTC
Zdenek,

this scratch build also crashes at the end of scanning.

Comment 16 Zdenek Dohnal 2019-03-14 09:07:55 UTC
Probably not enough space again... it was only one shot to try to prove my theory. Would you mind providing coredump when xsane crashes and xsane files from /tmp?

You get coredump when you set 'ulimit -c unlimited', delete content of /proc/sys/kernel/core_pattern, put 'core' string into the file and run xsane. When xsane crashes, coredump will be created in current directory (look like <PID>.core). f.e. https://radek.io/2012/02/11/core-dumps-in-fedora/

Comment 17 Steve 2019-03-14 10:04:06 UTC
The desired coredump of xsane (650MB):

https://send.firefox.com/download/cf02c62a23/#WjFCvkXJGWFkfB5mp4axWA

Comment 18 Zdenek Dohnal 2019-03-14 12:09:26 UTC
Thank you! Would you mind providing xsane files from /tmp too? Because there are specific settings in that files which I can help me a little.

Comment 19 Steve 2019-03-14 12:32:46 UTC
These /tmp files (xsane-preview-level*) are all 0 bytes big, they are empty.

Comment 20 Zdenek Dohnal 2019-03-14 12:57:59 UTC
Hmm... when I debugged xsane I had a file named 'xsane-conversion-<my-scanner>' there... would you mind run xsane in gdb, set breakpoint on xsane_viewer_read_image, run the binary and look into /tmp if there is a similar file?

Comment 21 Steve 2019-03-14 14:04:20 UTC
Ah, you mean this file. I thought this is an image (1.1GB):

https://send.firefox.com/download/8a6dc30258/#WZAOCb4fv9DF1_KKxC3i0w

Comment 22 Zdenek Dohnal 2019-03-15 09:04:55 UTC
Thank you for the file!

I had hope we have somehow similar machines, so coredump would work for me and I could play with it without any more info needed from you, but no luck with it... would you mind installing gtk2-debuginfo, creating a coredump as in https://bugzilla.redhat.com/show_bug.cgi?id=1688085#c16 , open it in gdb (gdb /usr/bin/xsane core.<PID>), run 'bt full', copying its output into a text file and attaching the file in the bugzilla as attachment?

Comment 23 Steve 2019-03-15 09:27:31 UTC
Created attachment 1544368 [details]
Output of gdb > bt full

Comment 24 Zdenek Dohnal 2019-03-15 11:01:08 UTC
I'm deeply sorry - I forgot to mention you need to have xsane-debuginfo installed too (I thought you already have, since backtrace from abrt has debug symbols). Would you mind repeating the last comment with xsane-debuginfo installed?

Comment 25 Steve 2019-03-15 12:17:46 UTC
I'm sorry too, but xsane-debuginfo is (was) already installed.

Comment 26 Zdenek Dohnal 2019-03-15 12:23:09 UTC
Hmm... because there is not any xsane function in the latest backtrace you attached... are you sure you opened it like:

$ gdb /usr/bin/xsane <your_coredump_file>

?

Comment 27 Steve 2019-03-15 12:27:16 UTC
I forgot to make a new coredump. In progress...

Comment 28 Steve 2019-03-15 12:54:11 UTC
So this is very strange. Xsane (0.999.30) is not crashing anymore. I can not reproduce this bug again. But why?

Comment 29 Zdenek Dohnal 2019-03-15 13:02:38 UTC
Tristan had a theory about xsane will crash when your /tmp (and / in matter of speaking) gets full with xsane tmp file (since pixmap with 4800dpi has over 1GB...), do not you have now more space in /tmp?

Comment 30 Steve 2019-03-16 18:02:56 UTC
No, i have not more space in tmp. My tmp is about 8 GB, where about 2 gb is needed for the scan. The rest is unused.


Note You need to log in before you can comment on or make changes to this bug.