[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
General PTY and CONSOLE question--SOLVED
- Date: Mon, 22 Sep 2008 10:16:43 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: General PTY and CONSOLE question--SOLVED
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
>>>> 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
>>> #1 0x201b2f9c in close (fd=0) at
>>> #2 0x201b302c in _close_r (ptr=0x2022d70c, fd=0) at
>>> #3 0x2021b2cc in _fclose_r (rptr=0x2022d70c, fp=0x2022da54) at
>>> #4 0x201b6370 in libc_wrapup () at
>>> #5 0x201b63f4 in _exit (status=0) at
>>> #6 0x201b32e4 in rtems_verror (error_flag=536870912,
>>> printf_format=0x202325d8 "bad tcgetattr", arglist=0x202523b0) at
>>> #7 0x201b33d0 in rtems_panic (printf_format=0x20164304 "") at
>>> #8 0x2016af00 in kbhit () at
>>> #9 0x201663ac in eip_cycle () at
>>> #10 0x201583cc in Init (ignored=0) at
>>> #11 0x2021aeb4 in _Thread_Handler () at
>>> #12 0x2021adf0 in _Thread_Is_heir (the_thread=0x202522b0) at
>> 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
>>> 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
>>> #1 0x201cd798 in rtems_bsdnet_free (addr=0x2031d150, type=3) at
>>> #2 0x201e5cac in sofree (so=0x201ce8b8) at
>>> #3 0x02000000 in ?? ()
>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 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.
> rtems-users mailing list
> rtems-users at rtems.com
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