wangtao13 commented on issue #19241:
URL: https://github.com/apache/nuttx/issues/19241#issuecomment-4861258183
@linguini1 With the following debug options, I hit another failure from
`assert`,
```
(0) Fortify Source
[*] Define NDEBUG globally
[*] Enable Debug Features
*** Debug SYSLOG Output Controls ***
[*] Enable Error Output
[*] Enable Warnings Output
[*] Enable Informational Debug Output
[*] Enable Debug Assertions
[ ] Enable Debug Assertions show expression
[*] Enable Debug Assertions show file name
*** Subsystem Debug Options ***
[*] Binary Loader Debug Features
[ ] Binary Loader Error Output
[ ] Binary Loader Warnings Output
[ ] Binary Loader Informational Output
[ ] File System Debug Features
[ ] Graphics Debug Features
[*] C Library Debug Features
[ ] C Library Error Output
[ ] C Library Warnings Output
[ ] C Library Informational Output
[ ] Queue Debug option
[*] Memory Manager Debug Features
[*] Memory Manager Error Output
[*] Memory Manager Warnings Output
[*] Memory Manager Informational Output
[ ] Power-related Debug Features
[ ] Battery-related Debug Features
[*] Scheduler Debug Features
[*] Scheduler Error Output
[*] Scheduler Warnings Output
[*] Scheduler Informational Output
*** OS Function Debug Options ***
[ ] Interrupt Controller Debug Features
*** Driver Debug Options ***
[ ] GPIO Debug Features
[ ] Memory Card Driver Debug Features
[ ] Thermal Debug Features
[ ] Timer Debug Features
[ ] Watchdog Timer Debug Features
[ ] IPC (Inter-Process Communication) Debug Features
(512) Stack overflow check size (bytes)
[*] Generate stack usage information
(0) Detect use of large stack variables
[*] Generate Debug Symbols
(-g) Custom symbols level
[*] Compile the NuttX with frame pointers
```
I attached gdb, and got following backtrace.
```
(gdb) bt
#0 __assert (filename=0x80192ef0 "semaphore/sem_post.c", linenum=106,
msg=0x0) at assert/lib_assert.c:38
#1 0x801558c4 in nxsem_post_slow (sem=0x8019c640 <g_uart2port+64>) at
semaphore/sem_post.c:105
#2 0x8010f358 in nxsem_post (sem=0x8019c640 <g_uart2port+64>) at
semaphore/sem_post.c:178
#3 0x8015ec14 in nxmutex_unlock (mutex=0x8019c640 <g_uart2port+64>) at
~/nuttx/nuttx/include/nuttx/mutex.h:573
#4 uart_writev (filep=0x801a23f8, uio=0x801a5604) at serial/serial.c:1564
#5 0x80139198 in file_writev (filep=0x801a23f8, iov=0x801a564c, iovcnt=1)
at vfs/fs_write.c:198
#6 0x80139258 in file_write (filep=0x801a23f8, buf=0x8018f450
<__FUNCTION__.6183>, nbytes=7) at vfs/fs_write.c:250
#7 0x8010cd18 in syslog_dev_write (channel=0x801a23d8, buffer=0x8018f450
<__FUNCTION__.6183> "mm_free", buflen=7) at syslog/syslog_device.c:497
#8 0x80189124 in syslog_write_foreach (buffer=0x8018f450
<__FUNCTION__.6183> "mm_free", buflen=7, force=false) at
syslog/syslog_write.c:166
#9 0x80189384 in syslog_write (buffer=0x8018f450 <__FUNCTION__.6183>
"mm_free", buflen=7) at syslog/syslog_write.c:263
#10 0x80167818 in syslograwstream_puts (self=0x801a5870, buff=0x8018f450
<__FUNCTION__.6183>, len=7) at stream/lib_syslograwstream.c:252
#11 0x80110318 in vsprintf_internal (stream=0x801a5870, arglist=0x0,
numargs=0, fmt=0x8018f442 ": Freeing %p\n", ap=0x801a5904) at
stream/lib_libvsprintf.c:945
#12 0x80110db8 in lib_vsprintf_internal (stream=0x801a5870, fmt=0x8018f440
"%s: Freeing %p\n", ap=0x801a5900) at stream/lib_libvsprintf.c:1443
#13 0x801601bc in nx_vsyslog (priority=6, fmt=0x8018f440 "%s: Freeing %p\n",
ap=0x801a58b8) at syslog/vsyslog.c:267
#14 0x8011158c in vsyslog (priority=6, fmt=0x8018f440 "%s: Freeing %p\n",
ap=0x801a5900) at syslog/lib_syslog.c:70
#15 0x80111610 in syslog (priority=6, fmt=0x8018f440 "%s: Freeing %p\n") at
syslog/lib_syslog.c:102
#16 0x80114164 in mm_free (heap=0x801a2140, mem=0x801a4af0) at
mm_heap/mm_free.c:234
#17 0x80112458 in free (mem=0x801a4af0) at umm_heap/umm_free.c:51
#18 0x8011a170 in up_release_stack (dtcb=0x801a4958, ttype=1 '\001') at
common/mips_releasestack.c:98
#19 0x80108a9c in nxsched_release_tcb (tcb=0x801a4958, ttype=1 '\001') at
sched/sched_releasetcb.c:136
#20 0x80157468 in nxtask_exit () at task/task_exit.c:148
#21 0x80119ba4 in up_exit (status=0) at common/mips_exit.c:63
#22 0x80153d6c in nx_pthread_exit (exit_value=0x0) at
pthread/pthread_exit.c:120
#23 0x8010e2d4 in pthread_exit (exit_value=0x0) at pthread/pthread_exit.c:71
#24 0x80162ec0 in pthread_startup (entry=0x8011b73c <task1>, arg=0x0) at
pthread/pthread_create.c:61
#25 0x80185b8c in pthread_start () at pthread/pthread_create.c:146
```
The assertion comes from line of 105, as follows,
```
91 if (mutex)
92 {
93 /* Mutex post from interrupt context is not allowed */
94
95 DEBUGASSERT(!up_interrupt_context());
96
97 /* Lock the mutex for us by setting the blocking bit */
98
99 mholder = atomic_fetch_or(NXSEM_MHOLDER(sem), NXSEM_MBLOCKING_BIT);
100
101 /* Mutex post from another thread is not allowed, unless
102 * called from nxsem_reset
103 */
104
105 DEBUGASSERT(mholder == (NXSEM_MBLOCKING_BIT | NXSEM_MRESET) ||
106 (mholder & (~NXSEM_MBLOCKING_BIT)) ==
nxsched_gettid());
107
108 blocking = NXSEM_MBLOCKING(mholder);
109
110 if (!blocking)
111 {
112 if (mholder != NXSEM_MRESET)
113 {
114 mholder = NXSEM_NO_MHOLDER;
115 }
116
117 atomic_set(NXSEM_MHOLDER(sem), mholder);
118 }
119 }
```
The `mholder` is 0x7ffffffd, and I think the failure is from
`nxsched_gettid()`. as follows,
```
53 pid_t nxsched_gettid(void)
54 {
55 FAR struct tcb_s *rtcb;
56
57 /* Get the TCB at the head of the ready-to-run task list. That
58 * will usually be the currently executing task. There are two
59 * exceptions to this:
60 *
61 * 1. Early in the start-up sequence, the ready-to-run list may be
62 * empty! In this case, of course, the CPU0 start-up/IDLE thread
with
63 * pid == 0 must be running, and
64 * 2. As described above, during certain context-switching conditions
the
65 * task at the head of the ready-to-run list may not actually be
66 * running.
67 */
68
69 rtcb = this_task();
70 if (rtcb != NULL)
71 {
72 /* Check if the task is actually running */
73
74 if (rtcb->task_state == TSTATE_TASK_RUNNING)
75 {
76 /* Yes.. Return the task ID from the TCB at the head of the
77 * ready-to-run task list
78 */
79
80 return rtcb->pid;
81 }
82
83 /* No.. return -ESRCH to indicate this condition */
84
85 return (pid_t)-ESRCH;
86 }
87
88 /* We must have been called earlier in the start up sequence from the
89 * start-up/IDLE thread before the ready-to-run list has been
initialized.
90 */
91
92 return 0;
93 }
```
Since the task is exiting, its state is `INACTIVE`, so it returns at line 85.
I am working on nuttx-12.13.0, and based on above logs, it is NOT right to
enable memory debug in my test case.
Is there any comments or suggestion?
Thanks,
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
