Subject | Re: Firebird V1.0 crash in strlen called from isc_dsql_prepare_m |
---|---|
Author | tomprice9876 |
Post date | 2007-06-26T00:30:55Z |
I have now reproduced this crash while gathering snoop of all
traffic on port 3050 on the server (this includes traffic from the 2
client machines I had doing database read operations, but not
transactions coming from the client process that runs on the server
itself). I have included a summary of this below, please let me
know if another format would be better.
Any insight that you can provide into what feature of my client
requests are triggering the crash would be greatly appreciated!
I see the following sequence in the snoop:
[snip]
23:30:20.014 server:3050 -> client1:2838 IB Reply dummy
23:30:20.014 server:3050 -> client1:2836 IB Reply dummy
23:30:20.014 server:3050 -> client2:4476 IB Reply dummy
23:30:20.015 server:3050 -> client2:4475 IB Reply dummy
23:30:20.015 server:3050 -> client2:4474 IB Reply dummy
23:30:20.229 client2:4476 -> server:3050 TCP ACK
23:30:20.229 client2:4475 -> server:3050 TCP ACK
23:30:20.229 client2:4474 -> server:3050 TCP ACK
23:30:20.349 client1:2836 -> server:3050 TCP ACK
23:30:20.350 client1:2838 -> server:3050 TCP ACK
23:30:47.180 client1:2838 -> server:3050 IB Request transaction
23:30:47.181 server:3050 -> client1:2838 IB Reply response
23:30:47.347 client1:2838 -> server:3050 IB Request allocate
statement
23:30:47.347 server:3050 -> client2:4500 IB Reply dummy
23:30:47.347 server:3050 -> client2:4499 IB Reply dummy
23:30:47.348 server:3050 -> client1:2838 IB Reply response
23:30:47.348 server:3050 -> client1:2837 IB Reply dummy
23:30:47.461 client2:4500 -> server:3050 TCP ACK
23:30:47.461 client2:4499 -> server:3050 TCP ACK
23:30:47.504 client1:2838 -> server:3050 IB Request prepare
statement
23:30:47.604 server:3050 -> client1:2838 TCP ACK
23:30:47.607 client1:2837 -> server:3050 TCP ACK
23:30:47.??? [ibserver crashes and dumps core]
23:30:52.222 All TCP connections close with [FIN, ACK] then [ACK]
The full list of TCP connections at the time of the crash was as
follows:
client1 ports 2836, 2837, 2838 <-> server port 3050
client2 ports 4474, 4475, 4476, 4499, 4500, 4501 <-> server port 3050
Note that the TCP packets containing the SQL that my client was
attempting to execute do not appear in the trace until after the
time of the crash, so I think that means they were never received by
the ibserver process and this crash is independent of the actual
query I am doing.
The call stack in this case was as follows.
----------------- lwp# 6094 / thread# 6094 --------------------
ff1b4478 strlen (694190, feb7b974, 513c70, 0, 0, 20) + 80
0002c030 isc_dsql_prepare_m (513c6c, feb7b97c, 590d70, 0, 0, 20) +
144
00025414 prepare_statement (590d60, feb7b9d0, 6d79e8, 6d7e6c,
5c60b8, 5c60b8) + 1ac
00025c70 process_packet (5c60b8, 6d7c68, 6d7c68, feb7bf8c, 0, 0) +
5a8
00027ad0 thread (1bd338, 1cf3f0, 0, 0, 0, 0) + 124
ff365e48 _lwp_start (0, 0, 0, 0, 0, 0)
Thanks,
Tom.
traffic on port 3050 on the server (this includes traffic from the 2
client machines I had doing database read operations, but not
transactions coming from the client process that runs on the server
itself). I have included a summary of this below, please let me
know if another format would be better.
Any insight that you can provide into what feature of my client
requests are triggering the crash would be greatly appreciated!
I see the following sequence in the snoop:
[snip]
23:30:20.014 server:3050 -> client1:2838 IB Reply dummy
23:30:20.014 server:3050 -> client1:2836 IB Reply dummy
23:30:20.014 server:3050 -> client2:4476 IB Reply dummy
23:30:20.015 server:3050 -> client2:4475 IB Reply dummy
23:30:20.015 server:3050 -> client2:4474 IB Reply dummy
23:30:20.229 client2:4476 -> server:3050 TCP ACK
23:30:20.229 client2:4475 -> server:3050 TCP ACK
23:30:20.229 client2:4474 -> server:3050 TCP ACK
23:30:20.349 client1:2836 -> server:3050 TCP ACK
23:30:20.350 client1:2838 -> server:3050 TCP ACK
23:30:47.180 client1:2838 -> server:3050 IB Request transaction
23:30:47.181 server:3050 -> client1:2838 IB Reply response
23:30:47.347 client1:2838 -> server:3050 IB Request allocate
statement
23:30:47.347 server:3050 -> client2:4500 IB Reply dummy
23:30:47.347 server:3050 -> client2:4499 IB Reply dummy
23:30:47.348 server:3050 -> client1:2838 IB Reply response
23:30:47.348 server:3050 -> client1:2837 IB Reply dummy
23:30:47.461 client2:4500 -> server:3050 TCP ACK
23:30:47.461 client2:4499 -> server:3050 TCP ACK
23:30:47.504 client1:2838 -> server:3050 IB Request prepare
statement
23:30:47.604 server:3050 -> client1:2838 TCP ACK
23:30:47.607 client1:2837 -> server:3050 TCP ACK
23:30:47.??? [ibserver crashes and dumps core]
23:30:52.222 All TCP connections close with [FIN, ACK] then [ACK]
The full list of TCP connections at the time of the crash was as
follows:
client1 ports 2836, 2837, 2838 <-> server port 3050
client2 ports 4474, 4475, 4476, 4499, 4500, 4501 <-> server port 3050
Note that the TCP packets containing the SQL that my client was
attempting to execute do not appear in the trace until after the
time of the crash, so I think that means they were never received by
the ibserver process and this crash is independent of the actual
query I am doing.
The call stack in this case was as follows.
----------------- lwp# 6094 / thread# 6094 --------------------
ff1b4478 strlen (694190, feb7b974, 513c70, 0, 0, 20) + 80
0002c030 isc_dsql_prepare_m (513c6c, feb7b97c, 590d70, 0, 0, 20) +
144
00025414 prepare_statement (590d60, feb7b9d0, 6d79e8, 6d7e6c,
5c60b8, 5c60b8) + 1ac
00025c70 process_packet (5c60b8, 6d7c68, 6d7c68, feb7bf8c, 0, 0) +
5a8
00027ad0 thread (1bd338, 1cf3f0, 0, 0, 0, 0) + 124
ff365e48 _lwp_start (0, 0, 0, 0, 0, 0)
Thanks,
Tom.