hplip segmentation fault when running packaged executables
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	DataDrake
	Aug 3 2016, 9:11 PM

Description

In hplip, nearly every executable will segmentation fault at some point during execution. Following this segmentation fault in a debugger revealed that it occurs whenever os.forkpty() is called in Python 2.7. Finding an obscure reference to a similar problem in the PyPy project, sufficient google-fu was applied to track down the source of the error. This led to the discovery of an issue on the Gentoo bug tracker to a similar effect:

https://bugs.gentoo.org/show_bug.cgi?id=584916

Comment 12 makes reference to a bug in glibc causing forkpty to behave incorrectly, as well as an upstream patch from Florien Weimer:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=patch;h=f06f3f05b48c72e2c9b0fa78671f94fd22d67da8

@ikey is currently working on a local Solus patch to the same effect. This still needs testing to verify that it does in fact correct os.forkpty() functionality. However, we will need to begin an upstream discussion to make sure this patch gets incorporated into future versions of glibc.

Event Timeline

DataDrake created this task.Aug 3 2016, 9:11 PM

Further details on this for the sake of debugging.. happens in Python 2 and Python 3

Python 2:

 ikey@solus-bdw  ~/Solus/glibc   master  python
Python 2.7.11 (default, Mar  2 2016, 14:16:26) 
[GCC 5.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.forkpty()
[1]    1586 segmentation fault (core dumped)  python
 ✘ ikey@solus-bdw  ~/Solus/glibc   master 

Stack trace from python2.7:

#0  0x0000000000000000 in ?? ()
#1  0x00007fb23753f6ce in forkpty (amaster=0x7ffca5fca194, 
    name=<optimized out>, termp=<optimized out>, winp=<optimized out>)
    at forkpty.c:34
#2  0x00007fb2380816e3 in ?? () from /usr/lib64/libpython2.7.so.1.0
#3  0x00007fb238039ce9 in PyEval_EvalFrameEx ()
   from /usr/lib64/libpython2.7.so.1.0
#4  0x00007fb23803d48c in PyEval_EvalCodeEx ()
   from /usr/lib64/libpython2.7.so.1.0
#5  0x00007fb23803d5a9 in PyEval_EvalCode ()
   from /usr/lib64/libpython2.7.so.1.0
#6  0x00007fb238062bb1 in PyRun_InteractiveOneFlags ()
   from /usr/lib64/libpython2.7.so.1.0
#7  0x00007fb238062dce in PyRun_InteractiveLoopFlags ()
   from /usr/lib64/libpython2.7.so.1.0
#8  0x00007fb2380635fe in PyRun_AnyFileExFlags ()
   from /usr/lib64/libpython2.7.so.1.0
#9  0x00007fb2380796c1 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007fb237965800 in __libc_start_main (main=0x400780 <main>, argc=1, 
    argv=0x7ffca5fca698, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7ffca5fca688)
---Type <return> to continue, or q <return> to quit---
    at ../csu/libc-start.c:289
#11 0x00000000004007b9 in _start ()

It appears as though this has already been sent upstream and pulled into glibc (2.22, 2.23, 2.24, master):

https://sourceware.org/bugzilla/show_bug.cgi?id=19861

See comments 7, 8, 9

Meta: Require update to glibc 2.24 in Solus

Thanks to this fine investigate by @DataDrake we now have unbroken forkpty() - and Python no longer segfaults.
Also confirmed hplip launches now.

Screenshot from 2016-08-03 22-31-19.png (1×1 px, 2 MB)

Resolving fixed, upstream patch backported solves issues.

Thanks again to @DataDrake for getting our glibc back in shape :)

	F209: Screenshot from 2016-08-03 22-31-19.png
	Aug 3 2016, 9:35 PM

hplip segmentation fault when running packaged executablesClosed, ResolvedPublicActions

Description

Event Timeline

hplip segmentation fault when running packaged executables
Closed, ResolvedPublic
Actions