[jira] [Created] (TS-753) More cleanup on API checks and return codes
More cleanup on API checks and return codes --- Key: TS-753 URL: https://issues.apache.org/jira/browse/TS-753 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 2.1.8 while reviewing some patches, I found a few more APIs that needs some cleanup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-751) Experimental TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash
[ https://issues.apache.org/jira/browse/TS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-751: Assignee: Leif Hedstrom > Experimental TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash > - > > Key: TS-751 > URL: https://issues.apache.org/jira/browse/TS-751 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: svn3.diff > > > If you use the API TSHttpTxnCacheLookupStatusSet() which is in experimental.h > but is potentially very handy, and you set the status to HIT_STALE TS > asserts. The code where it does that seems to be assuming that it is talking > to a parent proxy, but in our setup was talking to the origin server. The > fix seems pretty simple to make it handle talking to a origin server. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-751) Experimental TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash
[ https://issues.apache.org/jira/browse/TS-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-751. -- Resolution: Fixed Resolved, thanks William! > Experimental TSHttpTxnCacheLookupStatusSet(HIT_STALE) calls cause a crash > - > > Key: TS-751 > URL: https://issues.apache.org/jira/browse/TS-751 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: svn3.diff > > > If you use the API TSHttpTxnCacheLookupStatusSet() which is in experimental.h > but is potentially very handy, and you set the status to HIT_STALE TS > asserts. The code where it does that seems to be assuming that it is talking > to a parent proxy, but in our setup was talking to the origin server. The > fix seems pretty simple to make it handle talking to a origin server. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-752) cache scan issues
[ https://issues.apache.org/jira/browse/TS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-752: Assignee: Leif Hedstrom > cache scan issues > - > > Key: TS-752 > URL: https://issues.apache.org/jira/browse/TS-752 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: svn4.diff, svn4.diff, svn5.diff > > > Using the CacheScan plugin APIs I found a few issues. > Issue 1 is that if you cancel a scan really quickly you can get a NULL > dereference, the fix for this is easy. > Issue 2 is that the cache scan code can skip over entries if the initial > header overlaps a buffer boundary. > Issue 3 is that the cache scan code is crazy slow if your cache is not full, > it still scans everything. > I will attach a patch for Issues 2 & 3 mixed together... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-752) cache scan issues
[ https://issues.apache.org/jira/browse/TS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025159#comment-13025159 ] Leif Hedstrom commented on TS-752: -- William: Just to be safe, which of the patched submitted should be reviewed and committed? > cache scan issues > - > > Key: TS-752 > URL: https://issues.apache.org/jira/browse/TS-752 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell > Fix For: 2.1.8 > > Attachments: svn4.diff, svn4.diff, svn5.diff > > > Using the CacheScan plugin APIs I found a few issues. > Issue 1 is that if you cancel a scan really quickly you can get a NULL > dereference, the fix for this is easy. > Issue 2 is that the cache scan code can skip over entries if the initial > header overlaps a buffer boundary. > Issue 3 is that the cache scan code is crazy slow if your cache is not full, > it still scans everything. > I will attach a patch for Issues 2 & 3 mixed together... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-749) Connection hangs if origin server goes down in the middle of a response
[ https://issues.apache.org/jira/browse/TS-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-749: Assignee: Leif Hedstrom > Connection hangs if origin server goes down in the middle of a response > --- > > Key: TS-749 > URL: https://issues.apache.org/jira/browse/TS-749 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: svn.diff > > > If you start a long HTTP response, and then kill the origin web server, the > connection to the client goes idle. It looks like TS would accept further > commands, but the client doesn't know that the response is finished. After a > few minutes an idle timeout will close the connection. Instead the > connection should be closed, allowing the client to notice that it only got a > partial response in some cases, and letting it proceed in all cases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-621) writing 0 bytes to the HTTP cache means only update the header... need a new API: update_header_only() to allow 0 byte files to be cached
[ https://issues.apache.org/jira/browse/TS-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-621: - Fix Version/s: (was: 2.1.8) 2.1.9 Moving this out to v2.1.9 for now, in prep for the v2.1.8 release. Please move back if this will be fixed in the next few days. > writing 0 bytes to the HTTP cache means only update the header... need a new > API: update_header_only() to allow 0 byte files to be cached > - > > Key: TS-621 > URL: https://issues.apache.org/jira/browse/TS-621 > Project: Traffic Server > Issue Type: Improvement > Components: Cache >Affects Versions: 2.1.5 >Reporter: John Plevyak >Assignee: John Plevyak > Fix For: 2.1.9 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-753) More cleanup on API checks and return codes
[ https://issues.apache.org/jira/browse/TS-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-753. -- Resolution: Fixed > More cleanup on API checks and return codes > --- > > Key: TS-753 > URL: https://issues.apache.org/jira/browse/TS-753 > Project: Traffic Server > Issue Type: Improvement >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > > while reviewing some patches, I found a few more APIs that needs some cleanup. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-750) TS does not fail-over if one origin server for a 2 address hostname goes down
[ https://issues.apache.org/jira/browse/TS-750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-750: Assignee: Leif Hedstrom > TS does not fail-over if one origin server for a 2 address hostname goes down > - > > Key: TS-750 > URL: https://issues.apache.org/jira/browse/TS-750 > Project: Traffic Server > Issue Type: Bug > Components: HTTP >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: svn.diff2 > > > If you have a hostname that looks up to 2 addresses, and you make a request > to TS for something at that hostname, and then kill the origin server at > which ever address TS just talked to, your next request (if done promptly) > will fail with a 502 status code. A request made after that will fail-over > correctly. > Tracing the code I see it doing > proxy.config.http.connect_attempts_max_retries retries to the same address, > and it does call code to mark the address down after > proxy.config.http.connect_attempts_rr_retries attempts, the address does not > get marked down. > (The code calls HttpTransact::delete_server_rr_entry() which does > TRANSACT_RETURN(OS_RR_MARK_DOWN, ReDNSRoundRobin) which in turns tries to set > up the marking with HTTP_SM_SET_DEFAULT_HANDLER(&HttpSM::state_mark_os_down), > but state_mark_os_down never actually happens, instead it just goes into the > retry, I think based on ReDNSRoundRobin doing s->next_action = > how_to_open_connection(s).) > I have a fix, although it doesn't seem like quite the right way to go about > things, but I can't figure out how to get state_mark_os_down > to get called at the right time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-679) Make SDK APIs use struct sockaddr_storage instead of "unsigned int" for IPs
[ https://issues.apache.org/jira/browse/TS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-679: Assignee: Alan M. Carroll (was: Leif Hedstrom) Assigning this to Alan, since he's working on the struct sockaddr_storage migration. > Make SDK APIs use struct sockaddr_storage instead of "unsigned int" for IPs > --- > > Key: TS-679 > URL: https://issues.apache.org/jira/browse/TS-679 > Project: Traffic Server > Issue Type: Improvement > Components: TS API >Reporter: Leif Hedstrom >Assignee: Alan M. Carroll > Fix For: 2.1.9 > > > We should at a minimum make the necessary SDK changes to make the IP related > APIs IPv6 "compatible". Meaning, when we properly support IPv6, the APIs > should not have to change (again). > For some useful tips, see http://www.akkadia.org/drepper/userapi-ipv6.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-754) Reduce memory usage on idle connections
Reduce memory usage on idle connections --- Key: TS-754 URL: https://issues.apache.org/jira/browse/TS-754 Project: Traffic Server Issue Type: Improvement Reporter: Leif Hedstrom Fix For: 3.1 We should examine what memory (if any) can be returned to class allocators / freelist when a connection is idle (in keep-alive). Right now, I suspect we hold on to more memory than is necessary, which limits the number of KA connections a server can have. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-755) Should traffic_manager really start a new session?
Should traffic_manager really start a new session? -- Key: TS-755 URL: https://issues.apache.org/jira/browse/TS-755 Project: Traffic Server Issue Type: Bug Environment: Linux (Ubuntu, Fedora, all environments with upstart) Reporter: Igor Galić Fix For: 3.0 Unlike Solaris' SMF, which uses contract(4)s to track processes and their children, upstart simply uses sessions. When starting traffic_cop, this creates a new session, however, traffic_manager does the same. Through the new setsid(), upstart looses track of these children. When trying to stop, it only stops traffic_cop, leaving the rest of the system intact, albeit unsupervised. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-755) Should traffic_manager really start a new session?
[ https://issues.apache.org/jira/browse/TS-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Galić updated TS-755: -- Attachment: setsid.patch > Should traffic_manager really start a new session? > -- > > Key: TS-755 > URL: https://issues.apache.org/jira/browse/TS-755 > Project: Traffic Server > Issue Type: Bug > Environment: Linux (Ubuntu, Fedora, all environments with upstart) >Reporter: Igor Galić > Fix For: 3.0 > > Attachments: setsid.patch > > > Unlike Solaris' SMF, which uses contract(4)s to track processes and their > children, upstart simply uses sessions. > When starting traffic_cop, this creates a new session, however, > traffic_manager does the same. > Through the new setsid(), upstart looses track of these children. > When trying to stop, it only stops traffic_cop, leaving the rest of the > system intact, albeit unsupervised. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-752) cache scan issues
[ https://issues.apache.org/jira/browse/TS-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025251#comment-13025251 ] William Bardwell commented on TS-752: - The second svn4.diff (second attachment) should be reviewed and committed, and is small, fixing a crash in canceling. The svn5.diff (third attachment) should be reviewed and possibly committed, but it is larger and mixes in a performance improvement with the bug fix for entries on a read block boundary. > cache scan issues > - > > Key: TS-752 > URL: https://issues.apache.org/jira/browse/TS-752 > Project: Traffic Server > Issue Type: Bug > Components: Cache >Affects Versions: 2.1.7, 2.1.6, 2.1.5, 2.1.4 > Environment: Any >Reporter: William Bardwell >Assignee: Leif Hedstrom > Fix For: 2.1.8 > > Attachments: svn4.diff, svn4.diff, svn5.diff > > > Using the CacheScan plugin APIs I found a few issues. > Issue 1 is that if you cancel a scan really quickly you can get a NULL > dereference, the fix for this is easy. > Issue 2 is that the cache scan code can skip over entries if the initial > header overlaps a buffer boundary. > Issue 3 is that the cache scan code is crazy slow if your cache is not full, > it still scans everything. > I will attach a patch for Issues 2 & 3 mixed together... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-716) Crash in Continuation::handleEvent
[
https://issues.apache.org/jira/browse/TS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025301#comment-13025301
]
Kissdev commented on TS-716:
This time is OK when increase hostdb by a factor of 10. Thanks.
Just wondering why hostdb is increased so fast, since only 1,000 hosts are
cached. Maybe it is not related to this bug. It could be closed.
> Crash in Continuation::handleEvent
> ---
>
> Key: TS-716
> URL: https://issues.apache.org/jira/browse/TS-716
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.7
> Environment: CentOS 5.4 x86_64, 6 * 2T SATA Disks, 48G Memory
>Reporter: Kissdev
>Assignee: John Plevyak
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: crasher.patch
>
>
> ATS crashes with the following configuration:
> - reverse proxy , storage: 6 raw devices (6*2T), 1 partition (2T)
> - remap config:regex_map http://(.*) http://$1
> The load : about 100Mbps, requests for top 4000 internet sites, mainly
> html,js,pictures,flashes
> Detail of crashes by core dump:
> crash #1:
> {code}
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> 146 I_Continuation.h: No such file or directory.
> in I_Continuation.h
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> #1 0x00702b80 in EThread::process_event (this=0x2b101010,
> e=0x90f7170, calling_code=1) at UnixEThread.cc:140
> #2 0x00702fa1 in EThread::execute (this=0x2b101010) at
> UnixEThread.cc:232
> #3 0x007024d2 in spawn_thread_internal (a=0x8d94a70) at Thread.cc:85
> #4 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
> #5 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaaba360a11},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> {code}
> crash #2:
> {code}
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
> event=1, data=0x154b5a80) at I_Continuation.h:146
> #1 0x006db290 in InactivityCop::check_inactivity (this=0x154c8730,
> event=2, e=0x154b5a80) at UnixNet.cc:57
> #2 0x004dd1bb in Continuation::handleEvent (this=0x154c8730,
> event=2, data=0x154b5a80) at I_Continuation.h:146
> #3 0x00702b80 in EThread::process_event (this=0x2b606010,
> e=0x154b5a80, calling_code=2) at UnixEThread.cc:140
> #4 0x00702ec2 in EThread::execute (this=0x2b606010) at
> UnixEThread.cc:217
> #5 0x007024d2 in spawn_thread_internal (a=0x154852c0) at Thread.cc:85
> #6 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
> #7 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
> event=1, data=0x154b5a80) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x16280061},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> (gdb)
> {code}
> crash #3:
> {code}
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
> event=2, data=0x5631120) at I_Continuation.h:146
> #1 0x00702b80 in EThread::process_event (this=0x2abfc010,
> e=0x5631120, calling_code=2) at UnixEThread.cc:140
> #2 0x00702ec2 in EThread::execute (this=0x2abfc010) at
> UnixEThread.cc:217
> #3 0x0050917c in main (argc=3, argv=0x7fff0af6e3b8) at Main.cc:1962
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
> event=2, data=0x5631120) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaab45df291},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> {code}
--
This message is automatically
[jira] [Commented] (TS-716) Crash in Continuation::handleEvent
[
https://issues.apache.org/jira/browse/TS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025308#comment-13025308
]
John Plevyak commented on TS-716:
-
We should make another bug for this. I am not sure why, but it probably has
something to do with one or more of the sites having a large round robin and a
low TTL. It could also be exacerbated by a startup issue were a lot of
outstanding DNS requests for the same host are done unnecessarily. There is
supposed to be queuing in the DNS processor, but that may not be working as
intended
> Crash in Continuation::handleEvent
> ---
>
> Key: TS-716
> URL: https://issues.apache.org/jira/browse/TS-716
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.7
> Environment: CentOS 5.4 x86_64, 6 * 2T SATA Disks, 48G Memory
>Reporter: Kissdev
>Assignee: John Plevyak
>Priority: Critical
> Fix For: 2.1.8
>
> Attachments: crasher.patch
>
>
> ATS crashes with the following configuration:
> - reverse proxy , storage: 6 raw devices (6*2T), 1 partition (2T)
> - remap config:regex_map http://(.*) http://$1
> The load : about 100Mbps, requests for top 4000 internet sites, mainly
> html,js,pictures,flashes
> Detail of crashes by core dump:
> crash #1:
> {code}
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> 146 I_Continuation.h: No such file or directory.
> in I_Continuation.h
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> #1 0x00702b80 in EThread::process_event (this=0x2b101010,
> e=0x90f7170, calling_code=1) at UnixEThread.cc:140
> #2 0x00702fa1 in EThread::execute (this=0x2b101010) at
> UnixEThread.cc:232
> #3 0x007024d2 in spawn_thread_internal (a=0x8d94a70) at Thread.cc:85
> #4 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
> #5 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaaba364cb0,
> event=1, data=0x90f7170) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaaba360a11},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> {code}
> crash #2:
> {code}
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
> event=1, data=0x154b5a80) at I_Continuation.h:146
> #1 0x006db290 in InactivityCop::check_inactivity (this=0x154c8730,
> event=2, e=0x154b5a80) at UnixNet.cc:57
> #2 0x004dd1bb in Continuation::handleEvent (this=0x154c8730,
> event=2, data=0x154b5a80) at I_Continuation.h:146
> #3 0x00702b80 in EThread::process_event (this=0x2b606010,
> e=0x154b5a80, calling_code=2) at UnixEThread.cc:140
> #4 0x00702ec2 in EThread::execute (this=0x2b606010) at
> UnixEThread.cc:217
> #5 0x007024d2 in spawn_thread_internal (a=0x154852c0) at Thread.cc:85
> #6 0x0036ebc064a7 in start_thread () from /lib64/libpthread.so.0
> #7 0x0036eb0d3c2d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaabc0bce80,
> event=1, data=0x154b5a80) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x16280061},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> handler_name = 0xefefefefefefefef bounds>, mutex = {m_ptr = 0xefefefefefefefef}, link = {>
> = {
> next = 0xefefefefefefefef}, prev = 0xefefefefefefefef}}
> (gdb)
> {code}
> crash #3:
> {code}
> (gdb) bt
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
> event=2, data=0x5631120) at I_Continuation.h:146
> #1 0x00702b80 in EThread::process_event (this=0x2abfc010,
> e=0x5631120, calling_code=2) at UnixEThread.cc:140
> #2 0x00702ec2 in EThread::execute (this=0x2abfc010) at
> UnixEThread.cc:217
> #3 0x0050917c in main (argc=3, argv=0x7fff0af6e3b8) at Main.cc:1962
> (gdb) frame 0
> #0 0x004dd17a in Continuation::handleEvent (this=0x2aaab45d3a10,
> event=2, data=0x5631120) at I_Continuation.h:146
> 146 in I_Continuation.h
> (gdb) print *this
> $1 = { = {_vptr.force_VFPT_to_top = 0x2aaab45df291},
> handler = &virtual table offset -1157442765409226770, this adjustment
> -1157442765409226769,
> ha
