* [ECOS] Re: Network TCP Handler: stale socket disposal
@ 2007-09-25 12:20 Alok Singh
[not found] ` <6F6F9AF887E54B47961CA0F5D1C228D102129720@shake.airdefense.net>
0 siblings, 1 reply; 7+ messages in thread
From: Alok Singh @ 2007-09-25 12:20 UTC (permalink / raw)
To: johnmills; +Cc: ecos-discuss
Hi John,
What is the state of this issue?
Is your patch accepted?
Let us know the status, so that we can also pick up the changes.
Regards,
Alok
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Re: Network TCP Handler: stale socket disposal
[not found] ` <6F6F9AF887E54B47961CA0F5D1C228D102129720@shake.airdefense.net>
@ 2007-09-25 13:41 ` Alok Singh
2007-09-25 14:56 ` John Mills
0 siblings, 1 reply; 7+ messages in thread
From: Alok Singh @ 2007-09-25 13:41 UTC (permalink / raw)
To: Alok Singh, John Mills; +Cc: ecos-discuss
John,
Please post it in whatever form you deem as appropriate. Let us know when you will be able to post it.
BTW, I'm seeing a similar issue in my application. Sockets are exhausted, and web is not accessible. Ping is going through. I've kept Max. number of sockets as 32 while configuring ecos.
The strange thing is that the issue comes after a long period of inactivity, i.e., no web activity.
Your patch will be useful.
Regards,
Alok
________________________________________
From: John Mills [mailto:JMills@airdefense.net]
Sent: Tuesday, September 25, 2007 6:56 PM
To: Alok Singh
Cc: ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
All -
I don't believe my patch was ever accepted. The eCos sources carry a cautionary note that such a 'hung' socket may have been placed on the net stack 'accept' queue, and may be in the process of acceptance by a user thread which could then block.
I checked Linux and FreeBSD man pages on this. In Linux the blocked task would receive the next such incoming client and be unblocked. This is perfect for my application. Neither OpenBSD nor FreeBSD man pages address the issue specifically.
I didn't try to replicate the race condition myself.
eCos now uses an older version of the BSD stack, and updating it looks significant - well over a month's work, maybe 3 or 4 based on the time the original author reported for his port.
The patch solved a show-stopping problem with our application and seems to cause no problems, so we're using it. Two other users tried the approach and wrote me off-list: in one case it resolved a problem, in the other it made no difference (either way, as far as I know). I can share the patch on a "no warranty" basis, but would prefer to post it appropriately rather than circulating it randomly.
- John Mills
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org on behalf of Alok Singh
Sent: Tue 9/25/2007 8:20 AM
To: johnmills@speakeasy.net
Cc: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Re: Network TCP Handler: stale socket disposal
Hi John,
What is the state of this issue?
Is your patch accepted?
Let us know the status, so that we can also pick up the changes.
Regards,
Alok
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Re: Network TCP Handler: stale socket disposal
2007-09-25 13:41 ` Alok Singh
@ 2007-09-25 14:56 ` John Mills
2007-09-28 12:06 ` Alok Singh
0 siblings, 1 reply; 7+ messages in thread
From: John Mills @ 2007-09-25 14:56 UTC (permalink / raw)
To: Alok Singh; +Cc: John Mills, eCos Users
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2467 bytes --]
All -
First, please excuse my attaching a patch here, but I would like to
respond once (or a few times &8-) in case it's helpful.
Second, my reply to Mr. Singh failed posting because it originated from a
reader that can't enforce text-only formatting. Sorry.
Third, I post this patch for test and discussion purposes. It seems to
help in our limited case, but comes with no guarantee. I would appreciate
hearing others' experience.
Thanks for your patience.
- John Mills
On Tue, 25 Sep 2007, Alok Singh wrote:
> John,
> Please post it in whatever form you deem as appropriate. Let us know
> when you will be able to post it.
> BTW, I'm seeing a similar issue in my application. Sockets are
> exhausted, and web is not accessible. Ping is going through. I've kept
> Max. number of sockets as 32 while configuring ecos. The strange thing
> is that the issue comes after a long period of inactivity, i.e., no web
> activity. Â Â
> Your patch will be useful.
> Regards,
> Alok Â
> ________________________________________
> From: John Mills [mailto:JMills@airdefense.net]
> Sent: Tuesday, September 25, 2007 6:56 PM
> To: Alok Singh
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
> All -
> I don't believe my patch was ever accepted. The eCos sources carry a
> cautionary note that such a 'hung' socket may have been placed on the
> net stack 'accept' queue, and may be in the process of acceptance by a
> user thread which could then block.
> I checked Linux and FreeBSD man pages on this. In Linux the blocked task
> would receive the next such incoming client and be unblocked. This is
> perfect for my application. Neither OpenBSD nor FreeBSD man pages
> address the issue specifically.
> I didn't try to replicate the race condition myself.
> eCos now uses an older version of the BSD stack, and updating it looks
> significant - well over a month's work, maybe 3 or 4 based on the time
> the original author reported for his port.
> The patch solved a show-stopping problem with our application and seems
> to cause no problems, so we're using it. Two other users tried the
> approach and wrote me off-list: in one case it resolved a problem, in
> the other it made no difference (either way, as far as I know). I can
> share the patch on a "no warranty" basis, but would prefer to post it
> appropriately rather than circulating it randomly.
> Â - John Mills
[-- Attachment #2: Patch discards stale sockets --]
[-- Type: TEXT/PLAIN, Size: 907 bytes --]
--- /opt/ecos/ecos-2.0/packages/net/bsd_tcpip/v2_0/src/sys/kern/uipc_socket.c 2003-02-12 10:29:52.000000000 -0500
+++ ./uipc_socket.c 2007-08-28 16:11:56.000000000 -0400
@@ -242,6 +246,11 @@
TAILQ_REMOVE(&head->so_incomp, so, so_list);
head->so_incqlen--;
} else if (so->so_state & SS_COMP) {
+ if((so->so_error == ECONNRESET) ||
+ (so->so_error == ECONNREFUSED)){ // forced drop if flagged
+ TAILQ_REMOVE(&head->so_comp, so, so_list);
+ head->so_qlen--;
+ } else {
/*
* We must not decommission a socket that's
* on the accept(2) queue. If we do, then
@@ -249,11 +258,13 @@
* that the listening socket was ready.
*/
return;
+ }
} else {
panic("sofree: not queued");
}
head->so_qlen--;
so->so_state &= ~SS_INCOMP;
+ so->so_state &= ~SS_COMP;
so->so_head = NULL;
}
sbrelease(&so->so_snd, so);
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [ECOS] Re: Network TCP Handler: stale socket disposal
2007-09-25 14:56 ` John Mills
@ 2007-09-28 12:06 ` Alok Singh
2007-09-28 13:31 ` John Mills
0 siblings, 1 reply; 7+ messages in thread
From: Alok Singh @ 2007-09-28 12:06 UTC (permalink / raw)
To: John Mills; +Cc: eCos Users
Hi John/everybody,
The patch didn't work for me. I still had all the sockets exhausted, and so the web server hangs, and doesn't accept any new connection. The number of sockets I'm creating while configuring ECOS is 32. Please see the dump of " cyg_kmem_print_stats()" below when the problem comes.
Test case: I've a script that opens and closes connection to web server every second. It takes around 2 hours to exhaust the SOCKETS zone of sockets. The TCP zone of sockets also comes down. Even if I stop the script, the sockets never recover. I'm currently debugging it(trying to understand TCP by reading Comer and stevens).
Any ideas are welcome.
***************
cyg_kmem_print_stats() -
Network stack mbuf stats:
mbufs 32, clusters 6, free clusters 6
Failed to get 0 times
Waited to get 0 times
Drained queues to get 0 times
VM zone 'ripcb':
Total: 32, Free: 32, Allocs: 0, Frees: 0, Fails: 0
VM zone 'tcpcb':
Total: 32, Free: 1, Allocs: 3989, Frees: 3958, Fails: 0
VM zone 'udpcb':
Total: 32, Free: 31, Allocs: 14, Frees: 13, Fails: 0
VM zone 'socket':
Total: 32, Free: 0, Allocs: 10319, Frees: 3971, Fails: 6316
Misc mpool: total 131056, free 79008, max free block 77972
Mbufs pool: total 130944, free 128768, blocksize 128
Clust pool: total 262144, free 247808, blocksize 2048
***********************************************************
-Alok
-----Original Message-----
From: John Mills [mailto:johnmills@speakeasy.net]
Sent: Tuesday, September 25, 2007 8:26 PM
To: Alok Singh
Cc: John Mills; eCos Users
Subject: Re: [ECOS] Re: Network TCP Handler: stale socket disposal
All -
First, please excuse my attaching a patch here, but I would like to
respond once (or a few times &8-) in case it's helpful.
Second, my reply to Mr. Singh failed posting because it originated from a
reader that can't enforce text-only formatting. Sorry.
Third, I post this patch for test and discussion purposes. It seems to
help in our limited case, but comes with no guarantee. I would appreciate
hearing others' experience.
Thanks for your patience.
- John Mills
On Tue, 25 Sep 2007, Alok Singh wrote:
> John,
> Please post it in whatever form you deem as appropriate. Let us know
> when you will be able to post it.
> BTW, I'm seeing a similar issue in my application. Sockets are
> exhausted, and web is not accessible. Ping is going through. I've kept
> Max. number of sockets as 32 while configuring ecos. The strange thing
> is that the issue comes after a long period of inactivity, i.e., no web
> activity.
> Your patch will be useful.
> Regards,
> Alok
> ________________________________________
> From: John Mills [mailto:JMills@airdefense.net]
> Sent: Tuesday, September 25, 2007 6:56 PM
> To: Alok Singh
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
> All -
> I don't believe my patch was ever accepted. The eCos sources carry a
> cautionary note that such a 'hung' socket may have been placed on the
> net stack 'accept' queue, and may be in the process of acceptance by a
> user thread which could then block.
> I checked Linux and FreeBSD man pages on this. In Linux the blocked task
> would receive the next such incoming client and be unblocked. This is
> perfect for my application. Neither OpenBSD nor FreeBSD man pages
> address the issue specifically.
> I didn't try to replicate the race condition myself.
> eCos now uses an older version of the BSD stack, and updating it looks
> significant - well over a month's work, maybe 3 or 4 based on the time
> the original author reported for his port.
> The patch solved a show-stopping problem with our application and seems
> to cause no problems, so we're using it. Two other users tried the
> approach and wrote me off-list: in one case it resolved a problem, in
> the other it made no difference (either way, as far as I know). I can
> share the patch on a "no warranty" basis, but would prefer to post it
> appropriately rather than circulating it randomly.
> - John Mills
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [ECOS] Re: Network TCP Handler: stale socket disposal
2007-09-28 12:06 ` Alok Singh
@ 2007-09-28 13:31 ` John Mills
2007-10-02 9:15 ` Lars Povlsen
0 siblings, 1 reply; 7+ messages in thread
From: John Mills @ 2007-09-28 13:31 UTC (permalink / raw)
To: eCos Users; +Cc: Alok Singh
Alok -
Thanks for your feedback. That makes the success rate 50:50 (2 of 4
respondents) for the patch.
The web server in our product is a somewhat secondary administrative
function and we serve simple content that we control 100%. That allows me
to summarily close many browser inquiries. I have added and fixed the POST
code so it handles our binary firmware images. Either of these may have
closed some vulnerabilities that may be affecting you - I don't know.
Operationally our problem was triggered by vulnerability scanners used by
our customers' SysAdmins. These locked up our product in the course of
their overall test scenarios. In principle that meant we were also
vlunerable to the corresponding hacker exploits. That's what I meant in an
earlier post about a specific, observed functional problem.
The lock-up is broader than just web service. When the socket-descriptor
pool ('zone') is depleted, no new net sockets can be allocated. This
affected other, primary functions in our product, making it a critical
issue.
I traced the problem by putting 'diag_printf' lines at points where
sockets were created and deallocated, working down to find "what didn't
happen" when a socket was lost. Sounds like you have the same road ahead
of you.
Thanks again for your reaponse.
- John Mills
On Fri, 28 Sep 2007, Alok Singh wrote:
> Hi John/everybody,
> The patch didn't work for me. I still had all the sockets exhausted, and so the web server hangs, and doesn't accept any new connection. The number of sockets I'm creating while configuring ECOS is 32. Please see the dump of " cyg_kmem_print_stats()" below when the problem comes.
>
> Test case: I've a script that opens and closes connection to web server every second. It takes around 2 hours to exhaust the SOCKETS zone of sockets. The TCP zone of sockets also comes down. Even if I stop the script, the sockets never recover. I'm currently debugging it(trying to understand TCP by reading Comer and stevens).
>
> Any ideas are welcome.
>
> ***************
> cyg_kmem_print_stats() -
> Network stack mbuf stats:
> mbufs 32, clusters 6, free clusters 6
> Failed to get 0 times
> Waited to get 0 times
> Drained queues to get 0 times
> VM zone 'ripcb':
> Total: 32, Free: 32, Allocs: 0, Frees: 0, Fails: 0
> VM zone 'tcpcb':
> Total: 32, Free: 1, Allocs: 3989, Frees: 3958, Fails: 0
> VM zone 'udpcb':
> Total: 32, Free: 31, Allocs: 14, Frees: 13, Fails: 0
> VM zone 'socket':
> Total: 32, Free: 0, Allocs: 10319, Frees: 3971, Fails: 6316
> Misc mpool: total 131056, free 79008, max free block 77972
> Mbufs pool: total 130944, free 128768, blocksize 128
> Clust pool: total 262144, free 247808, blocksize 2048
> ***********************************************************
>
> -Alok
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [ECOS] Re: Network TCP Handler: stale socket disposal
2007-09-28 13:31 ` John Mills
@ 2007-10-02 9:15 ` Lars Povlsen
0 siblings, 0 replies; 7+ messages in thread
From: Lars Povlsen @ 2007-10-02 9:15 UTC (permalink / raw)
To: John Mills, eCos Users; +Cc: Alok Singh
Well,
Here's one more in favour... I reported a similar problem some moths
back, seen with MSIE 6.0 interacting with ATHTTPD. MSIE 6.0 is very
liberal in its use of sockets (actually quite chaotic...) - when the
problem is seen its opening sockets, sending data ("GET /...") - and
closing the socket again before getting ack on the data or even reading
data from the server.
The patch works, at least on the problems I was seeing.
---Lars
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of John Mills
Sent: 28. september 2007 15:31
To: eCos Users
Cc: Alok Singh
Subject: RE: [ECOS] Re: Network TCP Handler: stale socket disposal
Alok -
Thanks for your feedback. That makes the success rate 50:50 (2 of 4
respondents) for the patch.
The web server in our product is a somewhat secondary administrative
function and we serve simple content that we control 100%. That allows
me
to summarily close many browser inquiries. I have added and fixed the
POST
code so it handles our binary firmware images. Either of these may have
closed some vulnerabilities that may be affecting you - I don't know.
Operationally our problem was triggered by vulnerability scanners used
by
our customers' SysAdmins. These locked up our product in the course of
their overall test scenarios. In principle that meant we were also
vlunerable to the corresponding hacker exploits. That's what I meant in
an
earlier post about a specific, observed functional problem.
The lock-up is broader than just web service. When the socket-descriptor
pool ('zone') is depleted, no new net sockets can be allocated. This
affected other, primary functions in our product, making it a critical
issue.
I traced the problem by putting 'diag_printf' lines at points where
sockets were created and deallocated, working down to find "what didn't
happen" when a socket was lost. Sounds like you have the same road ahead
of you.
Thanks again for your reaponse.
- John Mills
On Fri, 28 Sep 2007, Alok Singh wrote:
> Hi John/everybody,
> The patch didn't work for me. I still had all the sockets exhausted,
and so the web server hangs, and doesn't accept any new connection. The
number of sockets I'm creating while configuring ECOS is 32. Please see
the dump of " cyg_kmem_print_stats()" below when the problem comes.
>
> Test case: I've a script that opens and closes connection to web
server every second. It takes around 2 hours to exhaust the SOCKETS zone
of sockets. The TCP zone of sockets also comes down. Even if I stop the
script, the sockets never recover. I'm currently debugging it(trying to
understand TCP by reading Comer and stevens).
>
> Any ideas are welcome.
>
> ***************
> cyg_kmem_print_stats() -
> Network stack mbuf stats:
> mbufs 32, clusters 6, free clusters 6
> Failed to get 0 times
> Waited to get 0 times
> Drained queues to get 0 times
> VM zone 'ripcb':
> Total: 32, Free: 32, Allocs: 0, Frees: 0, Fails: 0
> VM zone 'tcpcb':
> Total: 32, Free: 1, Allocs: 3989, Frees: 3958, Fails: 0
> VM zone 'udpcb':
> Total: 32, Free: 31, Allocs: 14, Frees: 13, Fails: 0
> VM zone 'socket':
> Total: 32, Free: 0, Allocs: 10319, Frees: 3971, Fails: 6316
> Misc mpool: total 131056, free 79008, max free block 77972
> Mbufs pool: total 130944, free 128768, blocksize 128
> Clust pool: total 262144, free 247808, blocksize 2048
> ***********************************************************
>
> -Alok
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* [ECOS] Re: Network TCP Handler: stale socket disposal
@ 2015-05-11 16:39 Weili Yao
0 siblings, 0 replies; 7+ messages in thread
From: Weili Yao @ 2015-05-11 16:39 UTC (permalink / raw)
To: ecos-discuss; +Cc: john.m.mills, gary, andrew
Hello John, Gary, and Andrew:
It seemed that John's patch proposal in the following post
https://www.sourceware.org/ml/ecos-patches/2007-08/msg00059.html
was not adopted by ECOS, but the patch indeed works for us. I put two devices using ECOS and put in our cooperation LAN side by side, one device with the patch and the other device without the patch. The device without the patch lost socketIDs, and the device with the patch has been running great. The backtrace shows as follows. I am not sure how to reproduce the problem, but when the devices are put in a big network, the patch code will be triggered and helped the free of socketIDs. Without the patch, the system slowly runs out of sockets and caused the system unaccessable.
My question is when the patch will be officially adopted by ECOS?
Thank you a lot!
Weili
(ECONNRESET is the so->error value) when reaching the patch code below:
(gdb) list *0x0010C8F0
0x10c8f0 is in debug_socket_patch (ecos/web/web_netinfo.c:501).
496 #include <sys/socketvar.h>
497 void debug_socket_patch(struct socket *so)
498 {
499 static int count = 0;
500 count++;
501 app_warning_error(fe_expro(), (count << 16) + so->so_error);
502 }
503
504 // end of the file
505
(gdb) list *0x003141D4
0x3141d4 is in cyg_sofree (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/sys/kern/uipc_socket.c:260).
255 head->so_incqlen--;
256 } else if (so->so_state & SS_COMP) {
257
258 if((so->so_error == ECONNRESET) ||
259 (so->so_error == ECONNREFUSED)){ // forced drop if flagged
260 debug_socket_patch(so);
261 TAILQ_REMOVE(&head->so_comp, so, so_list);
262 head->so_qlen--;
263 }
264 else
(gdb) list *0x003048F8
0x3048f8 is in cyg_in_pcbdetach (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/sys/netinet/in_pcb.c:528).
523 ipsec4_delete_pcbpolicy(inp);
524 #endif /*IPSEC*/
525 inp->inp_gencnt = ++ipi->ipi_gencnt;
526 in_pcbremlists(inp);
527 so->so_pcb = 0;
528 sofree(so);
529 if (inp->inp_options)
530 (void)m_free(inp->inp_options);
531 if (rt) {
532 /*
(gdb) list *0x00310FDC
0x310fdc is in cyg_tcp_close (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/sys/netinet/tcp_subr.c:748).
743 #ifdef INET6
744 if (INP_CHECK_SOCKAF(so, AF_INET6))
745 in6_pcbdetach(inp);
746 else
747 #endif /* INET6 */
748 in_pcbdetach(inp);
749 tcpstat.tcps_closed++;
750 return ((struct tcpcb *)0);
751 }
752
(gdb) list *0x0030DB58
0x30db58 is in cyg_tcp_input (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/sys/netinet/tcp_input.c:2074).
2069 * If our FIN is now acknowledged, delete the TCB,
2070 * enter the closed state and return.
2071 */
2072 case TCPS_LAST_ACK:
2073 if (ourfinisacked) {
2074 tp = tcp_close(tp);
2075 goto drop;
2076 }
2077 break;
2078
(gdb) list *0x00308700
0x308700 is in cyg_ip_input (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/sys/netinet/ip_input.c:951).
946 ip->ip_len -= hlen; // subtract the hlen
947 }
948
949 upper_layer:
950
951 (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, off);
952 #ifdef IPFIREWALL_FORWARD
953 ip_fw_fwd_addr = NULL; /* tcp needed it */
954 #endif
955 return;
(gdb) list *0x003087A8
0x3087a8 is in ipintr (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/sys/netinet/ip_input.c:979).
974 s = splimp();
975 IF_DEQUEUE(&ipintrq, m);
976 splx(s);
977 if (m == 0)
978 return;
979 ip_input(m);
980 }
981 }
982
983 /*
(gdb) list *0x002F987C
0x2f987c is in cyg_netint (/ecos_build/ecos_sources/packages/net/bsd_tcpip/current/src/ecos/support.c:757).
752 CYG_FLAG_WAITMODE_OR|CYG_FLAG_WAITMODE_CLR);
753 spl = splsoftnet(); // Prevent any overlapping "stack" processing
754 for (lvl = NETISR_MIN; lvl <= NETISR_MAX; lvl++) {
755 if (curisr & (1<<lvl)) {
756 if (NULL != _netisr_handlers[lvl])
757 (*_netisr_handlers[lvl])();
758 }
759 }
760 splx(spl);
761 }
(gdb) list *0x002D14B4
0x2d14b4 is in Cyg_HardwareThread::thread_entry(Cyg_Thread*) (/ecos_build/ecos_sources/packages/kernel/current/src/common/thread.cxx:94).
89 Cyg_Scheduler::scheduler.thread_entry( thread );
90
91 // Call entry point in a loop.
92 for(;;)
93 {
94 thread->entry_point(thread->entry_data);
95 thread->exit();
96 }
97 }
98
(gdb) list *0x002D147C
0x2d147c is in Cyg_Thread::exit() (/ecos_build/ecos_sources/packages/kernel/current/src/common/thread.cxx:781).
776
777 Cyg_Scheduler::scheduler.rem_thread(self);
778 }
779
780 Cyg_Scheduler::reschedule();
781 }
782
783 // -------------------------------------------------------------------------
784 // Kill thread. Force the thread into EXITED state externally, or
785 // make it wake up and call exit().
(gdb)
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-05-11 16:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-25 12:20 [ECOS] Re: Network TCP Handler: stale socket disposal Alok Singh
[not found] ` <6F6F9AF887E54B47961CA0F5D1C228D102129720@shake.airdefense.net>
2007-09-25 13:41 ` Alok Singh
2007-09-25 14:56 ` John Mills
2007-09-28 12:06 ` Alok Singh
2007-09-28 13:31 ` John Mills
2007-10-02 9:15 ` Lars Povlsen
2015-05-11 16:39 Weili Yao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).