Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Technology/tcpip : blown stack handling 0x102/List of Posts
Forum Topic - tcpip : blown stack handling 0x102: (11 Items)
   
Update
atish bhowmick(deleted)
10/28/2014 7:38 AM
post112189
tcpip : blown stack handling 0x102   
Platform : qnx 6.6 
I have written a io-pkt pfil library which can be configured to block some incoming & outgoing connections based on its 
attribute (source / remote IP & port nos.) 

I am getting a io-pkt crash(stack blown up) in a specific scenario : 

Allow incoming ssh on port 22 (local port) , but block all outgoing connections . So in this case sshd on qnx is unable 
to respond back to the incoming request .In that case the ssh connection wont get established as expected but io-pkt 
crashes immediately when this packet is dropped . 
Jan 02 04:34:54    1    14     0 tcpip: blown stack handling 0x102.  See "stacks
ize" option.

What can be the probable cause of this issue ? If sshd is not running or no incoming ssh request is made , crash doesn't
 occur . If the response is allowed no crash occurs.

Any help would be useful .
atish bhowmick(deleted)
10/28/2014 7:58 AM
post112190
Re: tcpip : blown stack handling 0x102   
also crash doesnt occur when i try to ssh out of the box and it gets blocked / dropped since all outgoing is blocked .
Nick Reilly
10/28/2014 8:49 AM
post112191
Re: tcpip : blown stack handling 0x102   
As the message says, you have blown the pseudo-thread stack. See the use message for io-pkt under the -p tcpip option

stacksize=X       - X is the size of each thread's stack in bytes.
                  - Default is 4096.

stackguard        - Introduce a guard page between each thread's stack to
                    aid in debugging "blown stack handling" panics. This will
                    cause a SIGSEGV at the point of stack overrun rather than
                    at the end of the operation.
                  - N.B. If stacksize is not a multiple of the system page
                    size then this option will increase the stacksize until
                    it is. A message will be logged to slogger in this case
                    advising of the new size. This increase in stacksize may
                    change the issue being debugged.
atish bhowmick(deleted)
10/28/2014 9:57 AM
post112192
Re: tcpip : blown stack handling 0x102   
I have tried increasing the stacksize but no success . I dont understand how this stack blowup is related to blocking / 
dropping of a packet through pfil hooks. It only happens if I block a response packet to incoming ssh connection request
 .I dont get any crash for blocking outgoing ssh connections.  I have faced similar stack blowup issues before & fixed 
my code (allocate lesser memory on stack) . Does this crash also mean I am using too much stack space in my pfil hook 
code?
Nick Reilly
10/28/2014 10:03 AM
post112193
Re: tcpip : blown stack handling 0x102   
Yes, you are using too much stack space. If you are hooked in through the pfil_ether_hook then that thread will have 
started down in the driver Rx routine as well.

I strongly recommend using the stackguard option to get it to fault at the point it overruns the stack. Without that it 
is overrunning the stack and then only getting caught when that pseudo-thread returns.
atish bhowmick(deleted)
10/29/2014 2:26 AM
post112214
Re: tcpip : blown stack handling 0x102   
increasing the stacksize is solving the crash . 
I also tried by introducing the stackguard option . As expected crash occurs much earlier rather than waiting for the 
end of hook . I get the following :

Process 565260 (io-pkt-v4-hc) terminated SIGSEGV code=2 fltno=11 ip=01077124(/usr/lib/ldqnx.so.2@difftime+0x1ac4) 
mapaddr=000771
24. ref=07f98fec

What can I conclude from this ?
Nick Reilly
10/29/2014 8:50 AM
post112217
Re: tcpip : blown stack handling 0x102   
That's the point at which it is exceeding the stack limit. Take a backtrace of the core file and then look through your 
functions in that backtrace for what their stack usage is.
atish bhowmick(deleted)
10/29/2014 9:50 AM
post112219
Re: tcpip : blown stack handling 0x102   
I get this crash only on ARM platform , no such crash on x86 . Is the default io-pkt stacksize different for these 
platforms ? 

when i launched io-pkt on ARM with stacksize=16k , crash didnt occur .
Sean Boudreau(deleted)
10/29/2014 9:57 AM
post112220
Re: tcpip : blown stack handling 0x102   
On Wed, Oct 29, 2014 at 09:50:54AM -0400, atish bhowmick wrote:
> I get this crash only on ARM platform , no such crash on x86 . Is the default io-pkt stacksize different for these 
platforms ? 

No.

> 
> when i launched io-pkt on ARM with stacksize=16k , crash didnt occur . 

As expected.  You're using too much stack.  You should try to keep the
stacksize option as low as possible since this value gets multiplied
by the number of coroutines (pseudo-threads) in use.

You should run io-pkt under the debugger and look at stack usage.  Look at the 'call
__stackavail()' command in gdb.
atish bhowmick(deleted)
10/29/2014 10:46 AM
post112221
Re: tcpip : blown stack handling 0x102   
Thats the strange part ... the same code executes fine with default stacksize=4k on x86 . 
But it causes stack blow up on ARM with same default stacksize . 

So I thought may b default stacksize on x86 is bigger than ARM .
Sean Boudreau(deleted)
10/29/2014 10:49 AM
post112223
Re: tcpip : blown stack handling 0x102   
The stack layout won't be exactly the same on the two architectures.
You may also just be lucky on x86 and not flip the majic bits on
this particular test.  Running with the stackguard option may
fault on both.

On Wed, Oct 29, 2014 at 10:46:57AM -0400, atish bhowmick wrote:
> Thats the strange part ... the same code executes fine with default stacksize=4k on x86 . 
> But it causes stack blow up on ARM with same default stacksize . 
> 
> So I thought may b default stacksize on x86 is bigger than ARM .
> 
> 
> 
> _______________________________________________
> 
> Technology
> http://community.qnx.com/sf/go/post112221
> To cancel your subscription to this discussion, please e-mail technology-networking-unsubscribe@community.qnx.com

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems