Issue Details (XML | Word | Printable)

Key: CORE-2415
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Alexander Peshkov
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Firebird crashes when out of /tmp space.

Created: 10/Apr/09 07:14 AM   Updated: 08/Nov/09 10:35 PM
Component/s: None
Affects Version/s: 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.1.0, 2.0.4, 2.1.1, 2.0.5, 2.1.2
Fix Version/s: 2.1.3, 2.0.6

Time Tracking:
Not Specified

Environment: linux, SS
Issue Links:
Relate
 

Planning Status: Unspecified


 Description  « Hide
This is how it dies:
(gdb) bt
#0  0x00a1a300 in pthread_mutex_lock () from /lib/libpthread.so.0
#1  0x082ef931 in Firebird::MemoryPool::deallocate (this=0x0, block=0xb79c7b98)
   at ../src/common/classes/locks.h:133 <<< ================ Invalid block deallocated
#2  0x082f632d in Firebird::status_exception::release_vector (this=0x1690)
   at ../src/common/classes/alloc.h:83
#3  0x082f639d in ~status_exception (this=0x96686a0) at ../src/common/fb_exception.cpp:184
#4  0x082f76ea in ~system_call_failed (this=0xb79c7b98)
#5  0x00abe708 in ?? () from /usr/lib/libstdc++.so.5
#6  0x00affcad in _Unwind_DeleteException () from /lib/libgcc_s.so.1
#7  0x00abd720 in __cxa_end_catch () from /usr/lib/libstdc++.so.5
#8  0x081e34c2 in merge_runs (scb=0xb747a8f4, n=15) at ../src/jrd/sort.cpp:1207
#9  0x081e1fcb in SORT_sort (tdbb=0xaf252b40, scb=0xb747a8f4) at ../src/jrd/sort.cpp:1001
#10 0x081db288 in open_sort (tdbb=0xaf252b40, rsb=0xaba14460, impure=0xaba13e0c,
   max_records=12620541087533057120) at ../src/jrd/rse.cpp:3007
#11 0x081d95f1 in RSE_open (tdbb=0xaf252b40, rsb=0xaba14460) at ../src/jrd/rse.cpp:438
#12 0x0815b595 in EVL_group (tdbb=0xaf252b40, rsb=0xaba14138, node=0xa45c8cc4, state=3)
   at ../src/jrd/evl.cpp:1531
#13 0x081da884 in get_record (tdbb=0xaf252b40, rsb=0xaba163fc, parent_rsb=0x0, mode=RSE_get_forward)
   at ../src/jrd/rse.cpp:2408
#14 0x081db08f in open_sort (tdbb=0xaf252b40, rsb=0xaba14090, impure=0xaba13e28,
   max_records=12620541087533056144) at ../src/jrd/rse.cpp:2941
#15 0x081d95f1 in RSE_open (tdbb=0xaf252b40, rsb=0xaba14090) at ../src/jrd/rse.cpp:438
#16 0x08165a68 in looper (tdbb=0xaf252b40, request=0xaba11d9c, in_node=0x1) at ../src/jrd/exe.cpp:1955
#17 0x08164700 in EXE_start (tdbb=0xaf252b40, request=0xaba11d9c, transaction=0xb75a52a0)
   at ../src/jrd/exe.cpp:1113
#18 0x0819ba00 in jrd8_start_request (user_status=0xaf253080, req_handle=0x1690, tra_handle=0x1690, level=0)
   at ../src/jrd/jrd.cpp:3830
#19 0x08081a1d in isc_start_request (user_status=0xaf253080, req_handle=0xab9d3f7c, tra_handle=0xab9d3f68,
   level=0) at ../src/jrd/why.cpp:446
#20 0x0824be05 in execute_request (request=0xab9d3f24, trans_handle=0x0, in_blr_length=8,
   in_blr=0xb73ae184 "\005\002\004", in_msg_length=16232, in_msg=0xae6f3304 "", out_blr_length=0,
   out_blr=0x0, out_msg_length=0, out_msg=0x0, singleton=false) at ../src/dsql/dsql.cpp:3405
#21 0x082492a1 in GDS_DSQL_EXECUTE_CPP (user_status=0x1690, trans_handle=0xaf25307c, req_handle=0x1690,
   in_blr_length=8, in_blr=0x1690 <Address 0x1690 out of bounds>, in_msg_type=0, in_msg_length=0,
   in_msg=0x1690 <Address 0x1690 out of bounds>, out_blr_length=0,
   out_blr=0x1690 <Address 0x1690 out of bounds>, out_msg_type=0, out_msg_length=0,
   out_msg=0x1690 <Address 0x1690 out of bounds>) at ../src/dsql/dsql.cpp:567
#22 0x0807a7b1 in isc_dsql_execute2_m (user_status=0xaf253080, tra_handle=0xaf25307c,
   stmt_handle=0xb760683c, in_blr_length=8, in_blr=0xb73ae184 "\005\002\004", in_msg_type=0,
   in_msg_length=0, in_msg=0xae6f3304 "", out_blr_length=0, out_blr=0x0, out_msg_type=0, out_msg_length=0,
   out_msg=0x0) at ../src/jrd/why.cpp:446
#23 0x08052fe3 in rem_port::execute_statement (this=0xb74e7f04, op=op_execute, sqldata=0xaf253080,
   sendL=0xb7606888) at ../src/remote/server.cpp:2150
#24 0x08058152 in process_packet2 (port=0xb74e7f04, sendL=0xb7606888, receive=0xb7606b3c, result=0xaf25334c)
---Type <return> to continue, or q <return> to quit---
   at ../src/remote/server.cpp:3612
#25 0x08055237 in process_packet (port=0xb74e7f04, sendL=0x1690, receive=0x1690, result=0xaf25334c)
   at ../src/remote/server.cpp:3363
#26 0x08058923 in loopThread (flags=0x2) at ../src/remote/server.cpp:5381
#27 0x080719b0 in threadStart (arg=0xb7c17134) at ../src/jrd/ThreadData.cpp:272
#28 0x00a1849b in start_thread () from /lib/libpthread.so.0
#29 0x0096f42e in clone () from /lib/libc.so.6


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 13/Apr/09 09:16 AM
Bug is caused by incorrect exceptions handling code, generated by gcc 3.2. Exception's destructor is executed twice - once in exception::raise() function, next in operator catch. Almost always it does not matter too much (in most cases destructor does nothing), but when temp strings are present in exception default memory pool gets corrupted.

Suppose this can be a cause of the whole variety of unexpected AVs. Looks like we need to build next release (at least 2.1, not sure for 2.0) using uprgaded build environment. Unfortunately, this requires C runtime (libgcc.so) upgrade on too old systems by the clients.

Alexander Peshkov added a comment - 15/Apr/09 01:56 AM
New build env with gcc 3.3.6 will be used to build 2.0 and 2.1 branches starting with versions 2.0.6 and 2.1.3. This may require libraries upgrade for people using linuxes released in year 2003 or before.