Bug 962221 - [abrt] par-1.52-8.fc18: freelines: Process /usr/bin/par was killed by signal 11 (SIGSEGV)
[abrt] par-1.52-8.fc18: freelines: Process /usr/bin/par was killed by signal ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: par (Show other bugs)
20
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Levine
Fedora Extras Quality Assurance
abrt_hash:35f0ed3efc4bfedbfd157062382...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-12 13:43 EDT by Joel Uckelman
Modified: 2015-01-18 20:33 EST (History)
1 user (show)

See Also:
Fixed In Version: par-1.52-16.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-18 20:33:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (29.69 KB, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: cgroup (131 bytes, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: core_backtrace (2.07 KB, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: dso_list (541 bytes, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: environ (3.25 KB, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: limits (1.29 KB, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: maps (1.75 KB, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: open_fds (222 bytes, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: proc_pid_status (930 bytes, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
File: var_log_messages (1.79 KB, text/plain)
2013-05-12 13:43 EDT, Joel Uckelman
no flags Details
bad input (82 bytes, application/octet-stream)
2013-05-12 13:44 EDT, Joel Uckelman
no flags Details

  None (edit)
Description Joel Uckelman 2013-05-12 13:43:27 EDT
Description of problem:
I fed par some particular UTF-8 input which I will attach after the bug report is submitted.

Version-Release number of selected component:
par-1.52-8.fc18

Additional info:
backtrace_rating: 4
cmdline:        par
crash_function: freelines
executable:     /usr/bin/par
foo:            Blah blah [1C]donate[1D] blah blah blah blah blah. Blah blah blah blah blah blah blah. 
kernel:         3.8.11-200.fc18.x86_64
uid:            1000
ureports_counter: 1

Truncated backtrace:
Thread no. 1 (1 frames)
 #18 freelines at par.c:707
Comment 1 Joel Uckelman 2013-05-12 13:43:30 EDT
Created attachment 746929 [details]
File: backtrace
Comment 2 Joel Uckelman 2013-05-12 13:43:32 EDT
Created attachment 746930 [details]
File: cgroup
Comment 3 Joel Uckelman 2013-05-12 13:43:34 EDT
Created attachment 746931 [details]
File: core_backtrace
Comment 4 Joel Uckelman 2013-05-12 13:43:36 EDT
Created attachment 746932 [details]
File: dso_list
Comment 5 Joel Uckelman 2013-05-12 13:43:38 EDT
Created attachment 746933 [details]
File: environ
Comment 6 Joel Uckelman 2013-05-12 13:43:40 EDT
Created attachment 746934 [details]
File: limits
Comment 7 Joel Uckelman 2013-05-12 13:43:42 EDT
Created attachment 746935 [details]
File: maps
Comment 8 Joel Uckelman 2013-05-12 13:43:44 EDT
Created attachment 746936 [details]
File: open_fds
Comment 9 Joel Uckelman 2013-05-12 13:43:46 EDT
Created attachment 746937 [details]
File: proc_pid_status
Comment 10 Joel Uckelman 2013-05-12 13:43:48 EDT
Created attachment 746938 [details]
File: var_log_messages
Comment 11 Joel Uckelman 2013-05-12 13:44:40 EDT
Created attachment 746939 [details]
bad input
Comment 12 Joel Uckelman 2013-05-12 13:51:22 EDT
My guess is that the U+001C and U+001D in the input are what's causing par to freak out.

When I run par in valgrind with this input, I get some invalid reads and writes:

[uckelman@scylla par]$ valgrind --tool=memcheck --leak-check=full --track-origins=yes par <foo
==14316== Memcheck, a memory error detector
==14316== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14316== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14316== Command: par
==14316== 
==14316== Invalid write of size 8
==14316==    at 0x4A0A38D: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882)
==14316==    by 0x404A9F: reformat (string3.h:51)
==14316==    by 0x401A74: main (par.c:896)
==14316==  Address 0x4c48140 is 288 bytes inside a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
==14316== Invalid write of size 4
==14316==    at 0x404C2F: reformat (reformat.c:544)
==14316==    by 0x401A74: main (par.c:896)
==14316==  Address 0x4c48148 is 4 bytes after a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
==14316== Invalid read of size 4
==14316==    at 0x4A0C014: wcslen (mc_replace_strmem.c:1600)
==14316==    by 0x3257455D9B: vfwprintf (vfprintf.c:1615)
==14316==    by 0x32575097CD: __fwprintf_chk (fwprintf_chk.c:36)
==14316==    by 0x401AA6: main (wchar2.h:347)
==14316==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
==14316== Invalid read of size 4
==14316==    at 0x3257470550: _IO_wdefault_xsputn (wgenops.c:352)
==14316==    by 0x32574726E0: _IO_wfile_xsputn (wfileops.c:965)
==14316==    by 0x3257455E6C: vfwprintf (vfprintf.c:1615)
==14316==    by 0x32575097CD: __fwprintf_chk (fwprintf_chk.c:36)
==14316==    by 0x401AA6: main (wchar2.h:347)
==14316==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14316==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14316==    by 0x4049A0: reformat (reformat.c:497)
==14316==    by 0x401A74: main (par.c:896)
==14316== 
Blah blah donate blah blah blah blah blah. Blah blah blah blah blah blah
blah.
==14316== 
==14316== HEAP SUMMARY:
==14316==     in use at exit: 0 bytes in 0 blocks
==14316==   total heap usage: 84 allocs, 84 frees, 7,063 bytes allocated
==14316== 
==14316== All heap blocks were freed -- no leaks are possible
==14316== 
==14316== For counts of detected and suppressed errors, rerun with: -v
==14316== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 2 from 2)

These aren't normal characters to have in text, but nonetheless, par should not crash.
Comment 13 Joel Uckelman 2013-05-12 14:13:42 EDT
More useful output from valgrind when I build par with debugging symbols (including all patches from the SRPM):

[uckelman@scylla par]$ valgrind --tool=memcheck --leak-check=full --track-origins=yes Par152/par <foo 
==14774== Memcheck, a memory error detector
==14774== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14774== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14774== Command: Par152/par
==14774== 
==14774== Invalid write of size 8
==14774==    at 0x4A0A38D: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:882)
==14774==    by 0x40590B: reformat (reformat.c:518)
==14774==    by 0x4042F4: main (par.c:892)
==14774==  Address 0x4c48140 is 288 bytes inside a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
==14774== Invalid write of size 4
==14774==    at 0x405B79: reformat (reformat.c:544)
==14774==    by 0x4042F4: main (par.c:892)
==14774==  Address 0x4c48148 is 4 bytes after a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
==14774== Invalid read of size 4
==14774==    at 0x4A0C014: wcslen (mc_replace_strmem.c:1600)
==14774==    by 0x3257455D9B: vfwprintf (vfprintf.c:1615)
==14774==    by 0x325746F476: fwprintf (fwprintf.c:34)
==14774==    by 0x40433C: main (par.c:899)
==14774==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
==14774== Invalid read of size 4
==14774==    at 0x3257470550: _IO_wdefault_xsputn (wgenops.c:352)
==14774==    by 0x32574726E0: _IO_wfile_xsputn (wfileops.c:965)
==14774==    by 0x3257455E6C: vfwprintf (vfprintf.c:1615)
==14774==    by 0x325746F476: fwprintf (fwprintf.c:34)
==14774==    by 0x40433C: main (par.c:899)
==14774==  Address 0x4c48144 is 0 bytes after a block of size 292 alloc'd
==14774==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==14774==    by 0x405711: reformat (reformat.c:497)
==14774==    by 0x4042F4: main (par.c:892)
==14774== 
Blah blah donate blah blah blah blah blah. Blah blah blah blah blah blah
blah.
==14774== 
==14774== HEAP SUMMARY:
==14774==     in use at exit: 0 bytes in 0 blocks
==14774==   total heap usage: 84 allocs, 84 frees, 7,063 bytes allocated
==14774== 
==14774== All heap blocks were freed -- no leaks are possible
==14774== 
==14774== For counts of detected and suppressed errors, rerun with: -v
==14774== ERROR SUMMARY: 5 errors from 4 contexts (suppressed: 2 from 2)
Comment 14 David Levine 2013-05-12 14:22:30 EDT
Will you be able to investigate and come up with a patch?  I won't have time for a while.
Comment 15 Joel Uckelman 2013-05-12 14:40:43 EDT
I was hoping you were more familiar with the code than I am, and you would see the easy fix to make. :)

Since sizeof(wchar_t) == 4 for me, and all of the invalid reads and writes valgrind finds go 4 bytes beyond the end of the allocated space, I'm guessing that everything here is caused by an off-by-one bug someplace, which is somehow triggered by the presence of the two unusual control characters.

It might be a while before working on this bubbles up to the top of my heap. (The previous problem affected me a lot more.) Then again, I might fix it tomorrow in a fit of pique. Who knows?
Comment 16 David Levine 2013-05-12 20:06:30 EDT
Sorry, you've already spent far more time in this code than I have :-)

Just to note that without the i18n patches, it doesn't seg fault and valgrind doesn't report any issues.
Comment 17 Joel Uckelman 2013-05-13 04:26:29 EDT
Thanks for checking that. I'll bet those two control characters are being misclassified/miscounted by something handling wide characters.
Comment 18 Fedora End Of Life 2013-12-21 08:30:25 EST
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Fedora End Of Life 2014-02-05 16:20:17 EST
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 David Levine 2014-02-05 16:52:08 EST
Moved to Fedora 20.
Comment 21 Fedora Update System 2014-12-25 00:47:22 EST
par-1.52-14.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/par-1.52-14.fc21
Comment 22 David Levine 2014-12-25 00:53:19 EST
Found it:
-    q1 = malloc((linelen + 1) * sizeof (wchar_t));
+    /* Added w1->length to provide space for non-printable characters. */
+    q1 = malloc((linelen + w1->length + 1) * sizeof (wchar_t));

at reformat.c:497.  I'm submitting updates for fc20 and fc21.
Comment 23 Fedora Update System 2014-12-25 00:59:11 EST
par-1.52-14.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/par-1.52-14.fc20
Comment 24 Fedora Update System 2014-12-25 09:24:42 EST
par-1.52-15.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/par-1.52-15.fc21
Comment 25 Fedora Update System 2014-12-25 09:25:21 EST
par-1.52-15.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/par-1.52-15.fc20
Comment 26 David Levine 2014-12-25 09:27:58 EST
I went with a better fix:
-    q1 = malloc((linelen + 1) * sizeof (wchar_t));
+    /* Added w1->length to provide space for multibyte characters. */
+    q1 = malloc((linelen + (w1 ? w1->length : 0) + 1) * sizeof (wchar_t));
Comment 27 Fedora Update System 2014-12-25 09:47:10 EST
par-1.52-15.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/par-1.52-15.fc19
Comment 28 Fedora Update System 2014-12-27 04:23:38 EST
Package par-1.52-15.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing par-1.52-15.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-17632/par-1.52-15.fc19
then log in and leave karma (feedback).
Comment 29 Fedora Update System 2015-01-05 02:33:33 EST
par-1.52-15.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 30 Fedora Update System 2015-01-05 02:34:21 EST
par-1.52-15.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 31 Fedora Update System 2015-01-05 02:36:41 EST
par-1.52-15.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 32 David Levine 2015-01-10 11:46:08 EST
Still buggy with multibyte characters, see below.  I am removing all of the par_1.52-i18n patches.

$ printf '\xe2\x97\x8f' | valgrind ./par
==2265== Memcheck, a memory error detector
==2265== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2265== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2265== Command: ./par
==2265== 
==2265== Conditional jump or move depends on uninitialised value(s)
==2265==    at 0x4036B2: setaffixes (par.c:696)
==2265==    by 0x404257: main (par.c:892)
==2265== 
==2265== Conditional jump or move depends on uninitialised value(s)
==2265==    at 0x404EDD: reformat (reformat.c:358)
==2265==    by 0x404349: main (par.c:902)
==2265== 
==2265== 
==2265== HEAP SUMMARY:
==2265==     in use at exit: 0 bytes in 0 blocks
==2265==   total heap usage: 80 allocs, 80 frees, 6,144 bytes allocated
==2265== 
==2265== All heap blocks were freed -- no leaks are possible
==2265== 
==2265== For counts of detected and suppressed errors, rerun with: -v
==2265== Use --track-origins=yes to see where uninitialised values come from
==2265== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Comment 33 Fedora Update System 2015-01-10 12:40:30 EST
par-1.52-16.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/par-1.52-16.fc21
Comment 34 Fedora Update System 2015-01-10 21:58:49 EST
Package par-1.52-16.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing par-1.52-16.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-0536/par-1.52-16.fc21
then log in and leave karma (feedback).
Comment 35 Fedora Update System 2015-01-18 20:33:22 EST
par-1.52-16.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

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