Зависание процессов classic на linux

[victor3000]

спасибо, вот такой ответ и был нужен. я удовлетворен. мне только не понятно одно, почему при малейшем намеке на ошибке в файрберде все разработчики становяться в позу кобры и пытаються ужалить, неужели не понятно что опонент не будет молчать в ответ. я бы в свою очередь наоборот заинтересовался таким "тестером", хотя бы по причине того что буквально с первых постов было понятно что проблема все же в файберде, достаточно логически подумать если работает без проблем на всех вариантах окромя cs linux. тем более я все рекомендации безоговорочно выполнял, и если внимательно перечитать все топики изначально то первым в бутылку не лез. или это все по причине "бесплатности" файрберда? так это как в пословице про мышиловку и бесплатный сыр, вот точно подходит.
я в принципе готов работать и на дебаг, или скорей всего куплю платный interbase, поскольку сейчас понимаю что с прогой все тип топ,
у вас же господа просто спрашиваю вы заинтересованы устранить проблему на не дебаговой версии или нет? если да давайте цивилизовано общаться, если нет прошу просто ответить нет. на сегодняшний день как это не смешно звучит вы больше заинтересованы нежели я. с огромным уважением Виктор.

[Dimitry Sibiryakov]

мне только не понятно одно, почему при малейшем намеке на ошибке в файрберде все разработчики становяться в позу кобры и пытаються ужалить

А как ты относишься к пользователям, которые сообщают, что в твоей программе баг, но не могут толком его описать и при этом заставить их сотрудничать и сделать хоть что-то для его локализации можно только пинками?

[dimitr]

1) данная проблема до сих пор в природе не встречалась. Поэтому гарантированно винить FB я бы не стал, хоть это и вероятно. И не надо рассказывать байки про толпы молчащих в тряпочку пользователей.

2) достаточных данных для диагностики проблемы (адекватного бэктрейса) предоставлено не было. Зато мы выслушали массу поучительных теорий про злокозненный lock timeout.

3) работоспособность с debug info - вообще из разряда необъяснимого. Это не дебаг-сборка, а просто символьная информация для gdb. Почему ее наличие напугало глюки, я без понятия.

продолжать искать стук в подвале смысла не вижу.

[v6y]

Насчет двойной блокировки в данном случая я прогнал - не могло здесь такого случится. Сорри.

[victor3000]

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7b130eb in semop () from /lib/libc.so.6
#2 0xb7cd6c86 in ISC_mutex_lock (mutex=0xbfc5f0a0)
at ../src/jrd/isc_sync.cpp:3288
#3 0xb7e570d5 in acquire (owner_offset=2189880) at ../src/lock/lock.cpp:1369
#4 0xb7e574b1 in blocking_action (_owner_offset=0x216a38)
at ../src/lock/lock.cpp:1726
#5 0xb7cd5d41 in signal_handler (number=16)
at ../src/jrd/os/posix/isc_ipc.cpp:581
#6 <signal handler called>
#7 0xffffe410 in __kernel_vsyscall ()
#8 0xb7b130eb in semop () from /lib/libc.so.6
#9 0xb7cd6c86 in ISC_mutex_lock (mutex=0xbfc5f4a0)
at ../src/jrd/isc_sync.cpp:3288
#10 0xb7d737c7 in acquire () at ../src/jrd/event.cpp:540
#11 0xb7d72de8 in EVENT_deliver () at ../src/jrd/event.cpp:1372
#12 0xb7d6836b in DFW_perform_post_commit_work (transaction=0xad304c8c)
at ../src/jrd/dfw.cpp:974
#13 0xb7df1caa in TRA_commit (tdbb=0xbfc5f6a0, transaction=0xad2ec88c,
retaining_flag=false) at ../src/jrd/tra.cpp:474
#14 0xb7db58ec in commit (user_status=0xbfc5f850, tra_handle=0x0,
retaining_flag=false) at ../src/jrd/jrd.cpp:4871
#15 0xb7dad49a in jrd8_commit_transaction (user_status=0xbfc5f850,
tra_handle=0xb782d304) at ../src/jrd/jrd.cpp:1601
#16 0xb7cde568 in isc_commit_transaction (user_status=0xb782d304,
tra_handle=0xb7830210) at ../src/jrd/why.cpp:1113
#17 0xb7e7df95 in rem_port::end_transaction (this=0xb7837e84,
operation=op_commit, release=0x0, sendL=0xbfc5fc90)
at ../src/remote/server.cpp:1782
#18 0xb7e809a4 in process_packet (port=0xb7837e84, sendL=0xbfc5fc90,
receive=0xbfc5fa10, result=0x0) at ../src/remote/server.cpp:3251
#19 0xb7e7cdbb in SRVR_main (main_port=0xb7837e84, flags=0)
at ../src/remote/server.cpp:267
#20 0xb7e7c99d in server_main (argc=0, argv=0xbfc60158)
at ../src/remote/inet_server.cpp:429
#21 0x08048569 in main (argc=0, argv=0x0) at ../src/remote/server_stub.cpp:12

вот получилось завесить с дебагом, наслаждайтесь

[victor3000]

в предыдущем посте на одном процессе был блок, а вот сдесь на 5.
вот бектрейсы всех.

1:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7af40eb in semop () from /lib/libc.so.6
#2 0xb7cb7c86 in ISC_mutex_lock (mutex=0xbfba94a0) at ../src/jrd/isc_sync.cpp:3288
#3 0xb7e380d5 in acquire (owner_offset=1175620) at ../src/lock/lock.cpp:1369
#4 0xb7e384b1 in blocking_action (_owner_offset=0x11f044) at ../src/lock/lock.cpp:1726
#5 0xb7cb6d41 in signal_handler (number=16) at ../src/jrd/os/posix/isc_ipc.cpp:581
#6 <signal handler called>
#7 signal_handler (number=0) at ../src/jrd/os/posix/isc_ipc.cpp:558
#8 <signal handler called>
#9 0xffffe410 in __kernel_vsyscall ()
#10 0xb7aebcdd in ___newselect_nocancel () from /lib/libc.so.6
#11 0xb7e3bf7d in packet_receive (port=0xb7818e84, buffer=0xb7818f6c "", buffer_length=8192, length=0xfffffffc) at ../src/remote/inet.cpp:3467
#12 0xb7e3bcf6 in inet_read (xdrs=0xb7818f04) at ../src/remote/inet.cpp:3148
#13 0xb7e3ba9a in inet_getbytes (xdrs=0xb7818f04, buff=0xbfbaa054 "", count=4) at ../src/remote/inet.cpp:2889
#14 0xb7e3bae1 in inet_getlong (xdrs=0xfffffffc, lp=0xfffffffc) at ../src/remote/inet.cpp:2910
#15 0xb7e501ff in xdr_enum (xdrs=0xbfba9cd0, ip=0xbfbaa160) at ../src/remote/xdr.cpp:431
#16 0xb7e4d47f in xdr_protocol (xdrs=0xb7818f04, p=0xbfbaa160) at ../src/remote/protocol.cpp:298
#17 0xb7e3f8bf in receive (main_port=0xb7818e84, packet=0xbfbaa160) at ../src/remote/inet.cpp:2286
#18 0xb7e4fc36 in rem_port::receive (this=0xfffffffc, pckt=0x0) at ../src/remote/remote.cpp:809
#19 0xb7e5dd9f in SRVR_main (main_port=0xb7818e84, flags=0) at ../src/remote/server.cpp:263
#20 0xb7e5d99d in server_main (argc=-4, argv=0xbfbaa8a8) at ../src/remote/inet_server.cpp:429
#21 0x08048569 in main (argc=-4, argv=0xfffffffc) at ../src/remote/server_stub.cpp:12

2:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7b210eb in semop () from /lib/libc.so.6
#2 0xb7ce4c86 in ISC_mutex_lock (mutex=0xbfe4c210) at ../src/jrd/isc_sync.cpp:3288
#3 0xb7e650d5 in acquire (owner_offset=1394852) at ../src/lock/lock.cpp:1369
#4 0xb7e654b1 in blocking_action (_owner_offset=0x1548a4) at ../src/lock/lock.cpp:1726
#5 0xb7ce3d41 in signal_handler (number=16) at ../src/jrd/os/posix/isc_ipc.cpp:581
#6 <signal handler called>
#7 signal_handler (number=-1387606372) at ../src/jrd/os/posix/isc_ipc.cpp:558
#8 <signal handler called>
#9 0xb7d4fec4 in BTR_make_key (tdbb=0xbfe50f00, count=1, exprs=0xad4acf2c, idx=0xad4ace68, key=0xbfe4fa90, fuzzy=false) at ../src/jrd/btr.cpp:1476
#10 0xb7d4ea09 in BTR_find_page (tdbb=0xbfe50f00, retrieval=0xad4ace68, window=0xbfe50aa0, idx=0xbfe50ac0, lower=0xbfe4fa90, upper=0xbfe4ea80,
backwards=false) at ../src/jrd/btr.cpp:775
#11 0xb7d4dd77 in BTR_evaluate (tdbb=0xbfe50f00, retrieval=0xad4ace68, bitmap=0xb7708b14) at ../src/jrd/btr.cpp:571
#12 0xb7d8273e in EVL_bitmap (tdbb=0xad4aed0c, node=0xad4aed0c) at ../src/jrd/evl.cpp:341
#13 0xb7dee7f7 in RSE_open (tdbb=0xbfe50f00, rsb=0xad4acf44) at ../src/jrd/rse.cpp:366
#14 0xb7d85b48 in eval_statistical (tdbb=0xbfe50f00, node=0xad53e2bc, impure=0xb7708af4) at ../src/jrd/evl.cpp:3006
#15 0xb7d835c3 in EVL_expr (tdbb=0xbfe50f00, node=0xad53e2bc) at ../src/jrd/evl.cpp:1012
#16 0xb7d8b21b in EXE_assignment (tdbb=0xbfe50f00, node=0xad53e2f4) at ../src/jrd/exe.cpp:280
#17 0xb7d8c702 in looper (tdbb=0xbfe50f00, request=0xb7707014, in_node=0xad0b4cec) at ../src/jrd/exe.cpp:1633
#18 0xb7d8c3b8 in execute_looper (tdbb=0xbfe50f00, request=0xb7707014, transaction=0xad53fc00, next_state=req_return) at ../src/jrd/exe.cpp:1251
#19 0xb7d8ba9e in EXE_receive (tdbb=0xbfe50f00, request=0xb7707014, msg=1, length=2172, buffer=0xad645020 "tв\001") at ../src/jrd/exe.cpp:599
#20 0xb7dbf60a in jrd8_receive (user_status=0xbfe51240, req_handle=0x1, msg_type=1, msg_length=2172, msg=0x1 <Address 0x1 out of bounds>, level=0)
at ../src/jrd/jrd.cpp:3097
#21 0xb7cf2b7c in isc_receive (user_status=0xbfe51240, req_handle=0x1, msg_type=1, msg_length=2172, msg=0x11 <Address 0x11 out of bounds>, level=0)
at ../src/jrd/why.cpp:3995
#22 0xb7e39751 in GDS_DSQL_FETCH_CPP (user_status=0x1, req_handle=0x1, blr_length=0, blr=0xad67dc88 "\005\002\004", msg_type=0, msg_length=2158,
dsql_msg_buf=0xad67fe48 "$\177#") at ../src/dsql/dsql.cpp:1109
#23 0xb7cf0821 in isc_dsql_fetch_m (user_status=0xbfe51240, stmt_handle=0x1, blr_length=0, blr=0xad67dc88 "\005\002\004", msg_type=0, msg_length=2158,
msg=0xad67fe48 "$\177#") at ../src/jrd/why.cpp:2994
#24 0xb7e8ca6f in rem_port::fetch (this=0xb7845e84, sqldata=0xbfe51638, sendL=0xbfe51680) at ../src/remote/server.cpp:2254
#25 0xb7e8e630 in process_packet (port=0xb7845e84, sendL=0xbfe51680, receive=0xbfe51400, result=0x0) at ../src/remote/server.cpp:3353
#26 0xb7e8adbb in SRVR_main (main_port=0xb7845e84, flags=0) at ../src/remote/server.cpp:267
#27 0xb7e8a99d in server_main (argc=1, argv=0xbfe51b48) at ../src/remote/inet_server.cpp:429
#28 0x08048569 in main (argc=1, argv=0x1) at ../src/remote/server_stub.cpp:12

3:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7b8c0eb in semop () from /lib/libc.so.6
#2 0xb7d4fc86 in ISC_mutex_lock (mutex=0xbf813e20) at ../src/jrd/isc_sync.cpp:3288
#3 0xb7ed00d5 in acquire (owner_offset=1789404) at ../src/lock/lock.cpp:1369
#4 0xb7ed04b1 in blocking_action (_owner_offset=0x1b4ddc) at ../src/lock/lock.cpp:1726
#5 0xb7d4ed41 in signal_handler (number=16) at ../src/jrd/os/posix/isc_ipc.cpp:581
#6 <signal handler called>
#7 signal_handler (number=-1227053062) at ../src/jrd/os/posix/isc_ipc.cpp:558
#8 <signal handler called>
#9 readNode (indexNode=0xbf8145d0,
pagePointer=0xb6dca7fa "\031№Т\t\f\006gЦ@\001їр\032№Т\t\f\006\202я`\001їр\024ЦТ\t\f\006\236ДА\001їр\033№Т\t\f\006\237э@\001їр\002\215Р\t
\f\006§м\200\001їр\025ЦТ\t\f\006Е_\220\001їр\030ЦТ\t\f\006ъR@\001їр\034ЦТ\t\v\a\212\fЎА\001їр\031ЦТ\t\f\006\027ЕP\
001їр\027ЦТ\t\f\006\037Ы \001їр\027\214Р\t\f\0061@А\001їр\213ЮС\t\022\036ЦТ\t\f\006Y; \001їр\003ЧТ\t\f\006iЬр\001їр\037ЦТ\t\f\006o\202@\001їр\005ЧТ\t\f\006\214О@\001їр\aЧТ\t\f\006\222s\220\001їр\004Ч"...,
flags=112 'p', leafNode=true) at ../src/jrd/btn.cpp:586
#10 0xb7e330ae in NAV_get_record (tdbb=0xbf8168d0, rsb=0xacf5e314, impure=0xace8c5ac, rpb=0xace89f14, direction=RSE_get_forward) at ../src/jrd/nav.cpp:281
#11 0xb7e5a61b in get_record (tdbb=0xbf8168d0, rsb=0xacf5e314, parent_rsb=0xacf60f08, mode=RSE_get_forward) at ../src/jrd/rse.cpp:1912
#12 0xb7e5a203 in get_record (tdbb=0xbf8168d0, rsb=0xacf60f08, parent_rsb=0x0, mode=RSE_get_forward) at ../src/jrd/rse.cpp:2141
#13 0xb7e59585 in RSE_get_record (tdbb=0xbf8168d0, rsb=0xacf60f08, mode=RSE_get_forward) at ../src/jrd/rse.cpp:266
#14 0xb7df7b83 in looper (tdbb=0xbf8168d0, request=0xace89da4, in_node=0xace89da4) at ../src/jrd/exe.cpp:1722
#15 0xb7df73b8 in execute_looper (tdbb=0xbf8168d0, request=0xace89da4, transaction=0xad55751c, next_state=25) at ../src/jrd/exe.cpp:1251
#16 0xb7df6a9e in EXE_receive (tdbb=0xbf8168d0, request=0xace89da4, msg=1, length=2172, buffer=0xacf1d4dc ":r\003") at ../src/jrd/exe.cpp:599
#17 0xb7e2a60a in jrd8_receive (user_status=0xbf816c10, req_handle=0x19, msg_type=1, msg_length=2172, msg=0x19 <Address 0x19 out of bounds>, level=0)
at ../src/jrd/jrd.cpp:3097
#18 0xb7d5db7c in isc_receive (user_status=0xbf816c10, req_handle=0x19, msg_type=1, msg_length=2172, msg=0xbf8145d0 "ъ§Ь¶\f", level=0)
at ../src/jrd/why.cpp:3995
#19 0xb7ea4751 in GDS_DSQL_FETCH_CPP (user_status=0x19, req_handle=0x19, blr_length=358, blr=0xad4e8c88 "\005\002\004", msg_type=0, msg_length=2158,
dsql_msg_buf=0xb78a6a44 "·\200#") at ../src/dsql/dsql.cpp:1109
#20 0xb7d5b821 in isc_dsql_fetch_m (user_status=0xbf816c10, stmt_handle=0x19, blr_length=358, blr=0xad4e8c88 "\005\002\004", msg_type=0, msg_length=2158,
msg=0xb78a6a44 "·\200#") at ../src/jrd/why.cpp:2994
#21 0xb7ef7b93 in rem_port::fetch (this=0xb78b0e84, sqldata=0xbf817008, sendL=0xbf817050) at ../src/remote/server.cpp:2177
#22 0xb7ef9630 in process_packet (port=0xb78b0e84, sendL=0xbf817050, receive=0xbf816dd0, result=0x0) at ../src/remote/server.cpp:3353
#23 0xb7ef5dbb in SRVR_main (main_port=0xb78b0e84, flags=0) at ../src/remote/server.cpp:267
#24 0xb7ef599d in server_main (argc=25, argv=0xbf817518) at ../src/remote/inet_server.cpp:429
#25 0x08048569 in main (argc=25, argv=0x19) at ../src/remote/server_stub.cpp:12

4:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7b760eb in semop () from /lib/libc.so.6
#2 0xb7d39c86 in ISC_mutex_lock (mutex=0xbffab450) at ../src/jrd/isc_sync.cpp:3288
#3 0xb7eba0d5 in acquire (owner_offset=1409396) at ../src/lock/lock.cpp:1369
#4 0xb7eba4b1 in blocking_action (_owner_offset=0x158174) at ../src/lock/lock.cpp:1726
#5 0xb7d38d41 in signal_handler (number=16) at ../src/jrd/os/posix/isc_ipc.cpp:581
#6 <signal handler called>
#7 0xffffe410 in __kernel_vsyscall ()
#8 0xb7b760eb in semop () from /lib/libc.so.6
#9 0xb7d39c86 in ISC_mutex_lock (mutex=0xbffab850) at ../src/jrd/isc_sync.cpp:3288
#10 0xb7dd67c7 in acquire () at ../src/jrd/event.cpp:540
#11 0xb7dd6d3b in deliver (arg=0x0) at ../src/jrd/event.cpp:965
#12 0xb7d38d41 in signal_handler (number=12) at ../src/jrd/os/posix/isc_ipc.cpp:581
#13 <signal handler called>
#14 0xb7da1b0b in readNode (indexNode=0xbffabd60, pagePointer=0xbffabd60 "\026ъЧ¶\f", flags=112 'p', leafNode=true) at ../src/jrd/btn.cpp:694
#15 0xb7e1d0ae in NAV_get_record (tdbb=0xbffae060, rsb=0xace28314, impure=0xacea65ac, rpb=0xacea3f14, direction=RSE_get_forward) at ../src/jrd/nav.cpp:281
#16 0xb7e4461b in get_record (tdbb=0xbffae060, rsb=0xace28314, parent_rsb=0xace2af08, mode=RSE_get_forward) at ../src/jrd/rse.cpp:1912
#17 0xb7e44203 in get_record (tdbb=0xbffae060, rsb=0xace2af08, parent_rsb=0x0, mode=RSE_get_forward) at ../src/jrd/rse.cpp:2141
#18 0xb7e43585 in RSE_get_record (tdbb=0xbffae060, rsb=0xace2af08, mode=RSE_get_forward) at ../src/jrd/rse.cpp:266
#19 0xb7de1b83 in looper (tdbb=0xbffae060, request=0xacea3da4, in_node=0xacea3da4) at ../src/jrd/exe.cpp:1722
#20 0xb7de13b8 in execute_looper (tdbb=0xbffae060, request=0xacea3da4, transaction=0xad3c2dac, next_state=12) at ../src/jrd/exe.cpp:1251
#21 0xb7de0a9e in EXE_receive (tdbb=0xbffae060, request=0xacea3da4, msg=1, length=2172, buffer=0xace674dc ":r\003") at ../src/jrd/exe.cpp:599
#22 0xb7e1460a in jrd8_receive (user_status=0xbffae3a0, req_handle=0xc, msg_type=1, msg_length=2172, msg=0xc <Address 0xc out of bounds>, level=0)
at ../src/jrd/jrd.cpp:3097
#23 0xb7d47b7c in isc_receive (user_status=0xbffae3a0, req_handle=0xc, msg_type=1, msg_length=2172, msg=0xfd <Address 0xfd out of bounds>, level=0)
at ../src/jrd/why.cpp:3995
#24 0xb7e8e751 in GDS_DSQL_FETCH_CPP (user_status=0xc, req_handle=0xc, blr_length=358, blr=0xad4d2c88 "\005\002\004", msg_type=0, msg_length=2158,
dsql_msg_buf=0xb7890a18 "·\200#") at ../src/dsql/dsql.cpp:1109
#25 0xb7d45821 in isc_dsql_fetch_m (user_status=0xbffae3a0, stmt_handle=0xc, blr_length=358, blr=0xad4d2c88 "\005\002\004", msg_type=0, msg_length=2158,
msg=0xb7890a18 "·\200#") at ../src/jrd/why.cpp:2994
#26 0xb7ee1b93 in rem_port::fetch (this=0xb789ae84, sqldata=0xbffae798, sendL=0xbffae7e0) at ../src/remote/server.cpp:2177
#27 0xb7ee3630 in process_packet (port=0xb789ae84, sendL=0xbffae7e0, receive=0xbffae560, result=0x0) at ../src/remote/server.cpp:3353
#28 0xb7edfdbb in SRVR_main (main_port=0xb789ae84, flags=0) at ../src/remote/server.cpp:267
#29 0xb7edf99d in server_main (argc=12, argv=0xbffaeca8) at ../src/remote/inet_server.cpp:429
#30 0x08048569 in main (argc=12, argv=0xc) at ../src/remote/server_stub.cpp:12

5:

#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7bc50eb in semop () from /lib/libc.so.6
#2 0xb7d88c86 in ISC_mutex_lock (mutex=0xbfb10d50) at ../src/jrd/isc_sync.cpp:3288
#3 0xb7e257c7 in acquire () at ../src/jrd/event.cpp:540
#4 0xb7e25d3b in deliver (arg=0x0) at ../src/jrd/event.cpp:965
#5 0xb7d87d41 in signal_handler (number=12) at ../src/jrd/os/posix/isc_ipc.cpp:581
#6 <signal handler called>
#7 0xffffe410 in __kernel_vsyscall ()
#8 0xb7bc50eb in semop () from /lib/libc.so.6
#9 0xb7d88c86 in ISC_mutex_lock (mutex=0xbfb11190) at ../src/jrd/isc_sync.cpp:3288
#10 0xb7f090d5 in acquire (owner_offset=2131844) at ../src/lock/lock.cpp:1369
#11 0xb7f094b1 in blocking_action (_owner_offset=0x208784) at ../src/lock/lock.cpp:1726
#12 0xb7d87d41 in signal_handler (number=16) at ../src/jrd/os/posix/isc_ipc.cpp:581
#13 <signal handler called>
#14 readNode (indexNode=0xbfb11660, pagePointer=0xbfb11660 "¬zН¶\004", flags=112 'p', leafNode=true) at ../src/jrd/btn.cpp:630
#15 0xb7df91be in find_node_start_point (bucket=0xb6cd4000, key=0xbfb12760, value=0x0, return_value=0xbfb1174e, descending=false, retrieval=false,
pointer_by_marker=false, find_record_number={value = 4047947732432820255}) at ../src/jrd/btr.cpp:4060
#16 0xb7df1e4b in BTR_evaluate (tdbb=0xbfb13bd0, retrieval=0xacefb5fc, bitmap=0xacf02720) at ../src/jrd/RecordNumber.h:47
#17 0xb7e2673e in EVL_bitmap (tdbb=0xacefb6d8, node=0xacefb6d8) at ../src/jrd/evl.cpp:341
#18 0xb7e927f7 in RSE_open (tdbb=0xbfb13bd0, rsb=0xacefb9c8) at ../src/jrd/rse.cpp:366
#19 0xb7e29b48 in eval_statistical (tdbb=0xbfb13bd0, node=0xad590918, impure=0xacf02700) at ../src/jrd/evl.cpp:3006
#20 0xb7e275c3 in EVL_expr (tdbb=0xbfb13bd0, node=0xad590918) at ../src/jrd/evl.cpp:1012
#21 0xb7e2f21b in EXE_assignment (tdbb=0xbfb13bd0, node=0xad3dc468) at ../src/jrd/exe.cpp:280
#22 0xb7e30702 in looper (tdbb=0xbfb13bd0, request=0xacf01014, in_node=0xad39c05c) at ../src/jrd/exe.cpp:1633
#23 0xb7e303b8 in execute_looper (tdbb=0xbfb13bd0, request=0xacf01014, transaction=0xad49daec, next_state=4895) at ../src/jrd/exe.cpp:1251
#24 0xb7e2fa9e in EXE_receive (tdbb=0xbfb13bd0, request=0xacf01014, msg=1, length=2172, buffer=0xace71020 "Яm\003") at ../src/jrd/exe.cpp:599
#25 0xb7e6360a in jrd8_receive (user_status=0xbfb13f10, req_handle=0x131f, msg_type=1, msg_length=2172, msg=0x131f <Address 0x131f out of bounds>, level=0)
at ../src/jrd/jrd.cpp:3097
#26 0xb7d96b7c in isc_receive (user_status=0xbfb13f10, req_handle=0x131f, msg_type=1, msg_length=2172, msg=0x0, level=0) at ../src/jrd/why.cpp:3995
#27 0xb7edd751 in GDS_DSQL_FETCH_CPP (user_status=0x131f, req_handle=0x131f, blr_length=0, blr=0xad521c88 "\005\002\004", msg_type=0, msg_length=2158,
dsql_msg_buf=0xad3f4694 "Е\200#") at ../src/dsql/dsql.cpp:1109
#28 0xb7d94821 in isc_dsql_fetch_m (user_status=0xbfb13f10, stmt_handle=0x131f, blr_length=0, blr=0xad521c88 "\005\002\004", msg_type=0, msg_length=2158,
msg=0xad3f4694 "Е\200#") at ../src/jrd/why.cpp:2994
#29 0xb7f30a6f in rem_port::fetch (this=0xb78e9e84, sqldata=0xbfb14308, sendL=0xbfb14350) at ../src/remote/server.cpp:2254
#30 0xb7f32630 in process_packet (port=0xb78e9e84, sendL=0xbfb14350, receive=0xbfb140d0, result=0x0) at ../src/remote/server.cpp:3353
#31 0xb7f2edbb in SRVR_main (main_port=0xb78e9e84, flags=0) at ../src/remote/server.cpp:267
#32 0xb7f2e99d in server_main (argc=4895, argv=0xbfb14818) at ../src/remote/inet_server.cpp:429
#33 0x08048569 in main (argc=4895, argv=0x131f) at ../src/remote/server_stub.cpp:12

[dimitr]

вот это уже много лучше, спасибо

[victor3000]

и в первом и во втором случае было около 12-20 конектов к базе, снимал только с тех бектрейс у которых по fb_lock_print видел блок(смотрел по pid). у остальных блоков не было но клиентские приложения висели.

[victor3000]

поставил firebird 2.0.1 rc2, блоки пока есть. такой вопрос а клиенты вместе с сервером обновляются? имею ввиду после обновления сервака всегда клиентов обновлять или там изменения происходят крайне редко?
p.s. дебаг инфа чем-то помогла?

[dimitr]

клиента обновлять не обязательно. debug-info помогла найти проблему, но решения пока нет. И я бы не стал обещать, что оно будет ранее 2.1.

[victor3000]

я очень рад что шанс на решение есть.

[adima]

клиента обновлять не обязательно. debug-info помогла найти проблему, но решения пока нет. И я бы не стал обещать, что оно будет ранее 2.1.

В последнее время опять слишком часто вылезать подобная проблема(блокирование процессов). Используется Firebird 1.5.2 под Линуксом. Помогает только отключение коннектов от базы. В связи с этим два вопроса есть:
1. Как можно определить, какой именно процесс блокирует все остальные? Судя по всему, автор топика находил его по выводу fb_lock_print.
2. Как в текущей версии можно обойти эту проблему? Есть ли это следствие употребления особых конструкций или параметров, которые можно изменить?

[WildSery]

Используется Firebird 1.5.2

Что мешает для начала обновить до 1.5.4 ?
Ведь может быть, что у тебя совсем не та проблема, которую тут нашли.

[victor3000]

1. Как можно определить, какой именно процесс блокирует все остальные? Судя по всему, автор топика находил его по выводу fb_lock_print.

fb_lock_print | less
потом листая в одном из блоков увидишь Blocks (1) вот например вот так:
OWNER BLOCK 27012
Owner id: 4085, type: 3, flags: 0x30, pending: 1630944, semid: 2
Process id: 4085, UID: 0x54 Alive
Flags: 0x70 hung wake
Requests (667): forward: 873480, backward: 1630944
Blocks (1): forward: 1859144, backward: 1859144
После смотри его пид в частности сдесь это 4085.
можно сразу прибить этот процесс kill -9 4085. и все. если нужно узнать какой это был из клиентов тогда перед kill пиши netstat -t -n -p
увидишь это
# netstat -t -n -p
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 192.168.0.99:3050 192.168.0.11:1142 ESTABLISHED 4085/fb_inet_server
видно что клиент это 192.168.0.11

2. Как в текущей версии можно обойти эту проблему? Есть ли это следствие употребления особых конструкций или параметров, которые можно изменить?

обойти можно просто. перейти на любой вариант firebird кроме linux classic.
если есть необходимость остаться на этой версии тогда свести к минимуму эвенты которые заставляют всех клиентов чтото писать в одни и те же таблицы. конечно функциональность задуманная в программе очень падает, но не все так плохо немного подождать и все исправят

[hvlad]

клиента обновлять не обязательно. debug-info помогла найти проблему, но решения пока нет. И я бы не стал обещать, что оно будет ранее 2.1.

В последнее время опять слишком часто вылезать подобная проблема(блокирование процессов). Используется Firebird 1.5.2 под Линуксом. Помогает только отключение коннектов от базы. В связи с этим два вопроса есть:
1. Как можно определить, какой именно процесс блокирует все остальные? Судя по всему, автор топика находил его по выводу fb_lock_print.
2. Как в текущей версии можно обойти эту проблему? Есть ли это следствие употребления особых конструкций или параметров, которые можно изменить?

1. 'способ' автора не корректен - он почти не отличается от 'научного тыка'. Автор неверно интерпретирует слово 'block' в выводе fb_lock_print и смотрит не туда.

Помогать автору в этом нет никакого желания из-за его регулярного хамства и провоцирования. Дискутировать на эту тему я не намерен, как и отвечать ему на что-либо

2. У автора проблема связана с употреблением event'ов и, возможно, раздутым кешем классика (это увеличивает вероятность конфликтов) или спецификой обработки этих самых event'ов (выяснять которую у меня нет никакого желания)

Я не вижу ни одного подтверждения что ваша проблема == проблеме автора.

[victor3000]

человек спросил как прибить одного клиента чтоб не убивать всех. метод который я описал работает 100%. когда метод работает 100%, то это не метод тыка а научный метод. кеш и увелиливал и уменьшал давно пройденый этап эффекта не имеет. Adima отпишись помог мой метод локализовать конкретного пользователя а не убивать всех, просто интересно.

[victor3000]

клиента обновлять не обязательно. debug-info помогла найти проблему, но решения пока нет. И я бы не стал обещать, что оно будет ранее 2.1.

Dimitr есть новости? На Вас только и надежда.

[dimitr]

проблема понятна, поставлена в очередь. Решения все еще нет.

[victor3000]

Вышла альфа 2.1. http://www.firebirdsql.org/index.php?op ... 10_alpha01 . Есть смысл переходить? То есть "моя" проблема исправлена?

[dimitr]

не исправлена