Bug 8192

Oh, code was cutted out.
http://pastebin.com/Ui0Rwmfn
http://pastebin.com/cvc3TKQV

Bug does not reproduced with x86_64 build with virtualbox. Also there is some strange behaviour with multiprocessing lib. Again, only on my board and not with virtualbox.

c code with fork works just fine http://pastebin.com/kJQemSzE

So, it definetly something "python-side"

python 3.3.3 from "fido" branch works just fine on my geode board.

I can confirm this isn't working, while I still don't exactly know what the problem is, I know its not related to python3 entirely, I was able to track the issue down to the Glibc upgrade from 2.21 to 2.22 on (which makes sense):

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=cb7368c110553dcb972480abc4a59b975677f7df

I will keep digging.

Created attachment 2734 [details]
strace_log_before_glibc_upgrade

Created attachment 2735 [details]
strace_log_after_glibc_upgrade

Following up on this issue; as it is shown on the attachments (trimmed strace logs before and after the upgrade) when using gilbc 2.22 the clone() syscall is never executed, hence why the waitpid() fails afterwards, I quickly skimmed through the modified patches, but didn't see anything at first sight that could be causing this behavior, so it might be something that changed upstream on glibc.

(In reply to comment #9)
Wow, awesome work! I have no experience with strace and such level of debugging, so I can't help, but I'm glad you can.

I'm still trying!, so this also seems to be x86 specific, I tested it on my local PC using Arch Linux (x86-64) with python 3.4 and glibc 2.22 and it worked!, so I also tested it on poky x86-64 and it worked just fine, ARM works fine too, which also may indicate that its something that changed upstream, since glibc implements fork in assembly and its architecture specific.

I tested this on Fedora 22 x86 using glibc 2.22 and python 3.4.2 and it works just fine, so I natively built python 3.4.2 on poky x86 linking to poky's glibc 2.22 and it worked fine as well, this means there's an issue with poky's Python3, either during compilation or with the patches

I tried building this with GCC 4.9 just to make sure it wasn't a GCC 5.* issue, I had the same result.

I tested on Jethro qemux86 python 3.4.3 and glibc 2.22 and works.

root@qemux86:~# python3.4 --version
Python 3.4.3
root@qemux86:~# cat yoba.py 
import os 
pid = os.fork()
if pid: 
    print("parent")
    os.waitpid(pid, 0)
else:
    print("child")
root@qemux86:~# python3   
python3            python3.4          python3.4m         
python3-config     python3.4-config   python3.4m-config  
root@qemux86:~# python3 yoba.py 
parent
child

hi multisosnooley,

Can you confirm that is failing on Jethro?

Regards,

(In reply to comment #15)
> Can you confirm that is failing on Jethro?
I will try, but this will took couple of days, since board are not with me right now.

I've just test jethro on my amd geode board (boot from usb stick) and simple python tests (os.fork and multiprocessing.Process) are ok. So, probably, this bug is covered by updates. I have no ability to play with python a lot (pip and libraries), since I can't install my linux build due some errors and I have no time and motivation to fix it.
But if Alejandro Hernandez still can reproduce this bug (AFAIR he can try to), then part(?) of bug is still there.

Its very likely, this was fixed by the updates, I will do a bisect to check what fixed it and mark this as solved afterwards

I just tested this on master (92cc02fe517bad0af4e493fda3331738cbcc9a26) using qemux86, and it's not working, so we're back were we started.

# python3.5 a.py 
parent
Traceback (most recent call last):
  File "a.py", line 8, in <module>
    os.waitpid(pid, 0)
ChildProcessError: [Errno 10] No child processes

moving it to minor since this is a very sporadic issue. Will continue working in it though.

Hi,

We recently ran into a strange issue that seems very similar.
Yocto: 2.01 (Jethro)
Python: 3.4.3
Platform: imx6 (ARM Cortex-a9)

The issue we saw was that we couldn't start new processes using multiprocess.Process in python.


We were able to work around this issue in a very odd way.
After installing an image on our target, we used smart to remove python3, and then re-installed it using a rpm package repository built from the same tree as the original image.


After playing around with installing images/rpms we managed to narrowed the problem down to os.fork() returning something very bad.
(In fact, it turned out it returned a pointer to the fork() function from libc)

When running the two different scenarios (clean image vs re-installed python3) through gdb we could see that in the case where os.fork() fails, resolve_fork() is invoked instead of fork(). And resolve_fork() returns the pointer to the actual fork() function.

We do not know why this is yet, it is still very strange, "posixmodule.c" from the python sources calls fork(), but for some reason, from a fresh install the function invoked is resolve_fork().

Sorry, that should be fork_resolve() rather than resolve_fork()

Looks like this may be the same problem:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9131

(In reply to comment #23)
> Looks like this may be the same problem:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=9131

I can confirm this is the same problem, disabling pre-linking works , and since it is disabled as default, we shouldn't have a problem for now.

Changing the status to NEEDINFO, until the pre linking issue gets fixed.

It shouldn't be moved to NEEDINFO if it is dependent on another bug.  I have assigned it to Mark.  If is is a duplicate, it should be closed as duplicate.  Also moved it to Medium since the comments show it is not a major issue.

Could you retest this please? We enabled prelink for x86 again in August with updates to fix some of these issues.

I Ran it again
Setting LD_USE_LOAD_BIAS=1 when starting

Yocto: master
Python: 3.5.2
Platform: qemux86
--------------------------------------------------

sh-4.3# export LD_USE_LOAD_BIAS=1
sh-4.3# cat yoba.py
import os 
pid = os.fork()
if pid: 
    print("parent")
    os.waitpid(pid, 0)
else:
    print("child")
sh-4.3# python3 yoba.py
parent
child

I've forgotten to add the revision ( 14539203655913b3304bf98d2dd1f2e1fed3d7ca )

We have set LD_USE_LOAD_BIAS with value 1 as per resolution in bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=9131

*** This bug has been marked as a duplicate of bug 9131 ***