General PTY and CONSOLE question--SOLVED
Joel Sherrill
joel.sherrill at OARcorp.com
Mon Sep 22 15:16:43 UTC 2008
Gene Smith wrote:
> Joel Sherrill wrote, On 09/22/2008 09:50 AM:
>
>> Gene Smith wrote:
>>
>>> Gene Smith wrote, On 09/21/2008 08:23 PM:
>>>
>>>
>>>> failed internally with no CONSOLE driver enabled. You end up with a
>>>> stack like this:
>>>>
>>>> Kbhit() <--- my function
>>>> rtems_panic
>>>> rtems_verror
>>>> _exit
>>>> newlibc_exit
>>>> close(stdin/stdout/stderr)
>>>> soisdisconnected <--sets SS_CANTRCVMORE bit that accept() fails on.
>>>>
>>>>
>>>>
>>> The stack actually looks like this (eventually you reach
>>> soisdisconnected() as shown above):
>>>
>>> (arm-gdb) bt
>>> #0 rtems_bsdnet_close (iop=0x202ca83c) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libnetworking/rtems/rtems_syscall.c:672
>>> #1 0x201b2f9c in close (fd=0) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/close.c:33
>>> #2 0x201b302c in _close_r (ptr=0x2022d70c, fd=0) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/close.c:56
>>> #3 0x2021b2cc in _fclose_r (rptr=0x2022d70c, fp=0x2022da54) at
>>> ../../../../../gcc-4.2.4/newlib/libc/stdio/fclose.c:93
>>> #4 0x201b6370 in libc_wrapup () at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:88
>>> #5 0x201b63f4 in _exit (status=0) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:131
>>> #6 0x201b32e4 in rtems_verror (error_flag=536870912,
>>> printf_format=0x202325d8 "bad tcgetattr", arglist=0x202523b0) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/error.c:162
>>> #7 0x201b33d0 in rtems_panic (printf_format=0x20164304 "") at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/error.c:210
>>> #8 0x2016af00 in kbhit () at
>>> /home/gene/4.8.0-rtems/tools/network-demos-4.8.0/adapter/ertek209/cep/src/linux_conio.c:102
>>> #9 0x201663ac in eip_cycle () at
>>> /home/gene/4.8.0-rtems/tools/network-demos-4.8.0/adapter/ertek209/cep/src/EepSample.c:515
>>> #10 0x201583cc in Init (ignored=0) at
>>> /home/gene/4.8.0-rtems/tools/network-demos-4.8.0/adapter/ertek209/mgt/src/init.c:99
>>> #11 0x2021aeb4 in _Thread_Handler () at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/score/src/threadhandler.c:137
>>> #12 0x2021adf0 in _Thread_Is_heir (the_thread=0x202522b0) at
>>> ../../cpukit/../../../csb337/lib/include/rtems/score/thread.inl:60
>>>
>>>
>>>
>> I think newlib/exit is doing what we expect it to do -- close stdin, out
>> and error. The system is not in an unusual state (critical section or
>> shutting down).
>>
>> Is it possible that these sequences are not in the same thread? Or are
>> we closing a socket that is not completely/correctly initialized?
>>
>> I can't connect the pieces in my head to see what went wrong. Is
>> the socket closed twice? Not completely initialized?
>>
>> Can you put some traces into soclose() at uipc_socket.c:156 so
>> we can tell if this is the first or second close?
>>
>> The malloc message is often indicative of a double free.
>>
>> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
>>
>>> r0) at 0x201b5e7c.
>>> 0x0) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/malloc.c:495
>>> 495 printk( "Program heap: free of bad pointer %p -- range %p -
>>> %p \n",
>>> Current language: auto; currently c
>>> (arm-gdb) bt
>>> #0 free (ptr=0x2031d150) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libcsupport/src/malloc.c:495
>>> #1 0x201cd798 in rtems_bsdnet_free (addr=0x2031d150, type=3) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libnetworking/rtems/rtems_glue.c:137
>>> #2 0x201e5cac in sofree (so=0x201ce8b8) at
>>> ../../../../../../rtems-4.8.0/c/src/../../cpukit/libnetworking/kern/uipc_socket.c:156
>>> #3 0x02000000 in ?? ()
>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>>>
>>> (arm-gdb)
>>>
>
> Joel,
> Here is my understanding (possibly over simplified) of what is
> happening: Yes, there are two threads here, 1) my application still
> containing kbhit() function and 2) the standard 4.8.0 telnetd. Since I
> have no CONSOLE driver enabled, the first socket() call returns 0 which
> is the "des_socket" used in telnetd. This gets opened OK.
Right. First call to open() gets fd=0.
> Then my task
> runs and fails on the kbhit() due to no CONSOLE driver. I call
> rtems_panic() which eventually reaches the point where stdin (also FD 0,
> I think) is called.
Not exactly. rtems_panic() called exit() which closes
stdin, out, and error
> The chain of code realizes FD 0 is a socket and
> closes it, freeing some memory and setting the SS_CANTRCVMORE bit in the
> so_state for socket 0. After this, but before everything shuts down, the
> accept() call in telnetd sees this SS_CANTRCVMORE flag and returns a -1.
> This causes the endless loop to exit and the "des_socket" 0 is closed.
> Since FD 0 was already closed by the _fclose(stdin) this caused the
> malloc/free error that I see in telnetd.
>
>
Sounds like the socket close code has no idea that it shouldn't
close it a second time. Somehow we get deep in the bowels
for a closed file descriptor. I wonder if simply calling close()
twice on a socket fd would reproduce the problem.
> So I think the problem is:
> 1) socket allocation starts at 0 when there is no console driver
> (instead of 3 when there is).
> 2) _fclose(stdin=0) occurs when there is no console (I assume stdin was
> never opened?)
>
Right. Not having /dev/console results in this. When
/dev/console is present, the three open() calls for stdin,
out, and error will open 0-2.
I think it is just a long weird chain of things. But somehow
the socket close code doesn't know it has already been closed.
> 3) I called rtems_panic() in my user program.
>
> Not doing 3 fixes the situation for me.
>
> -gene
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users
mailing list