-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mutexLock inside __fflush_unlocked fails after psh run prog #1077
Closed
Labels
Comments
I've reproduced the issue on (gdb) backtrace
#0 mutexLock (m=4) at /path-to-project/phoenix-rtos-project/libphoenix/sys/threads.c:20
#1 0x0805ede5 in __fflush_unlocked (lock=lock@entry=1, stream=0x0)
at /path-to-project/phoenix-rtos-project/libphoenix/stdio/file.c:637
#2 0x0805f4ef in __fflush_unlocked (lock=1, stream=0x0)
at /path-to-project/phoenix-rtos-project/libphoenix/stdio/file.c:636
#3 0x08068493 in execve (file=0x212a "/bin/bind", argv=0x21a8, envp=0x2208)
at /path-to-project/phoenix-rtos-project/libphoenix/unistd/sys.c:106
#4 0x080688b6 in execv (path=0x212a "/bin/bind", argv=0x21a8)
at /path-to-project/phoenix-rtos-project/libphoenix/unistd/sys.c:94
#5 0x08049d75 in psh_runscript (path=path@entry=0xbfffffd8 "/etc/rc.psh")
at /path-to-project/phoenix-rtos-project/phoenix-rtos-utils/psh/pshapp/pshapp.c:1348
#6 0x0804a180 in psh_pshapp (argv=<optimized out>, argc=<optimized out>)
at /path-to-project/phoenix-rtos-project/phoenix-rtos-utils/psh/pshapp/pshapp.c:1802
#7 psh_pshapp (argc=<optimized out>, argv=<optimized out>)
at /path-to-project/phoenix-rtos-project/phoenix-rtos-utils/psh/pshapp/pshapp.c:1771
#8 0x08048774 in main (argc=<optimized out>, argv=<optimized out>)
at /path-to-project/phoenix-rtos-project/phoenix-rtos-utils/psh/psh.c:182 |
Apparently it is caused by copying resources from parent only in |
astalke
added a commit
to phoenix-rtos/phoenix-rtos-kernel
that referenced
this issue
May 27, 2024
Move copying of resources from `process_copy` to `vfork`. Fixes: phoenix-rtos/phoenix-rtos-project#1077 JIRA: RTOS-839
Merged
14 tasks
astalke
added a commit
to phoenix-rtos/phoenix-rtos-kernel
that referenced
this issue
May 27, 2024
Move copying of resources from `process_copy` to `process_vforkThread`. Fixes: phoenix-rtos/phoenix-rtos-project#1077 JIRA: RTOS-839
astalke
added a commit
to phoenix-rtos/phoenix-rtos-kernel
that referenced
this issue
May 27, 2024
Move copying of resources from `process_copy` to `process_vforkThread`. Fixes: phoenix-rtos/phoenix-rtos-project#1077 JIRA: RTOS-839
astalke
added a commit
to phoenix-rtos/phoenix-rtos-kernel
that referenced
this issue
May 27, 2024
Move copying of resources from `process_copy` to `process_vforkThread`. Fixes: phoenix-rtos/phoenix-rtos-project#1077 JIRA: RTOS-839
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I put some trap in mutexLock code (thanks @xvuko for asserion test as an inspiration)
Then attempt to run app via psh (it can be just typed aa in psh)
The traps hits from execve path in from __flush_unlocked.
handle_t seems to have resonable value (probably from parent after (v)fork) but it not exist for the newly forked process
Backtrace below
I debug it on armv7m4-stm32l4-nucleo, but issues probably hits all architectures.
The text was updated successfully, but these errors were encountered: