General PTY and CONSOLE question--SOLVED

[Gene Smith]

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. 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. 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.

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?)
3) I called rtems_panic() in my user program.

Not doing 3 fixes the situation for me.

-gene