Right. Yes, I had a typo. I meant that it shouldn't die on seeing a
read EOF after closing the write side of the socket.
So, what you're saying is:
* nc sees EOF on stdin
* nc decides to abort before seeing the rest of the data come in from
the remote socket (and then trying to write it, and
On Friday, July 19, 2013 10:16:15 pm Yuri wrote:
On 07/19/2013 14:04, John Baldwin wrote:
Hmm, that definitely looks like garbage. How are you with gdb scripting?
You could write a script that walks the PQ_ACTIVE queue and see if this
pointers ends up in there. It would then be
On Friday, July 19, 2013 1:45:11 pm rank1see...@gmail.com wrote:
I had 2 panics: (Both occured at 3 AM, so had to be daily task)
First (Jul 2 03:06:50 2013):
--
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x19
fault code = supervisor read, page
In message caj-vmokahe+uy4-3qaw6mk__sgw+l2_y6m29o_+x+ak5hoa...@mail.gmail.com
Adrian Chadd adr...@freebsd.org wrote:
Right. Yes, I had a typo. I meant that it shouldn't die on seeing a
read EOF after closing the write side of the socket.
So, what you're saying is:
* nc sees EOF on stdin
Yes.
Right, and your patch just stops the shutdown(), right? Rather than
teaching nc to correctly check BOTH socket states before deciding to
close things.
I'd personally rather see nc taught to check to see whether it can
possibly make ANY more progress before deciding to shut things down.
-adrian
5 matches
Mail list logo