Skip to content
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
anglov opened this issue May 16, 2024 · 2 comments · Fixed by phoenix-rtos/phoenix-rtos-kernel#553
Closed
Labels

Comments

@anglov
Copy link
Member

anglov commented May 16, 2024

I put some trap in mutexLock code (thanks @xvuko for asserion test as an inspiration)

diff --git a/sys/threads.c b/sys/threads.c
index 42ecf87..f7e5c2a 100644
--- a/sys/threads.c
+++ b/sys/threads.c
@@ -17,10 +17,17 @@
 #include <errno.h>
 
 
+static int trap() {
+       while(1) {
+       }
+}
+
 int mutexLock(handle_t m)
 {
        int err;
        while ((err = phMutexLock(m)) == -EINTR) ;
+       if (err < 0)
+               trap();
        return err;
 }

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

#0  mutexLock (m=5) at /path/to/project/libphoenix/sys/threads.c:30
#1  0x0803acd0 in __fflush_unlocked (lock=1, stream=<optimized out>) at /path/to/project/libphoenix/stdio/file.c:637
#2  0x08040aea in execve (file=0x20021c20 "as", argv=argv@entry=0x200175c0 <phfs_common+884>, envp=0x20019ffc) at /path/to/project/libphoenix/unistd/sys.c:106
#3  0x08040d3c in execv (path=<optimized out>, argv=argv@entry=0x200175c0 <phfs_common+884>) at /path/to/project/libphoenix/unistd/sys.c:94
#4  0x0803397a in psh_runfile (argc=<optimized out>, argv=0x200175c0 <phfs_common+884>) at /path/to/project/phoenix-rtos-utils/psh/runfile/runfile.c:51
#5  0x0802ae42 in psh_run (console=0x80416f0 "/dev/console", exitable=1) at /path/to/project/phoenix-rtos-utils/psh/pshapp/pshapp.c:1731
#6  psh_pshapp (argc=<optimized out>, argv=<optimized out>) at /path/to/project/phoenix-rtos-utils/psh/pshapp/pshapp.c:1806
#7  0x0802949e in main (argc=1, argv=0x20019ff4) at /path/to/project/phoenix-rtos-utils/psh/psh.c:182
#8  0x0802967c in _startc (cleanup=0x0, argc=1, argv=0x20019ff4, env=<optimized out>) at /path/to/project/libphoenix/crt0-common.c:92
#9  0x08012058 in process_exec (current=0x0, spawn=0xffffffcc) at /path/to/project/phoenix-rtos-kernel/proc/process.c:1130

I debug it on armv7m4-stm32l4-nucleo, but issues probably hits all architectures.

@anglov anglov added the kernel label May 16, 2024
@astalke
Copy link
Contributor

astalke commented May 24, 2024

I've reproduced the issue on ia32-generic-qemu.

(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

@astalke
Copy link
Contributor

astalke commented May 27, 2024

Apparently it is caused by copying resources from parent only in fork, but not in vfork.

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
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
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants