Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FB 2 RC 4 Linux Classic server crashes! Bug (CORE-914) still exists [CORE944] #1345

Closed
firebird-automations opened this issue Sep 29, 2006 · 13 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Radek Palmowski (palma)

Relate to CORE982

Server crashes when using IB_UDF library (I think so). It is occurs randomly and it is difficult to reproduce.
Debugger (gdb) show segmentation fault in func.cpp FUN_evaluate.

The generated core file for this bug is here:
http://vgakey.net/public/firebird/core.28623.bz2

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Radek Palmowski (palma)

Breakpoint 1, FUN_evaluate (function=0xb5c6c6d8, node=0xb5c6c58c, value=0xb5c6b8fc) at ../src/jrd/fun.cpp:1066
1066 UCHAR* temp_ptr = CALL_UDF(function->fun_entrypoint, pUCHAR);
5: function->fun_type = 0
4: function->fun_count = 2
3: function->fun_args = 2
2: function->fun_entrypoint = (int (*)(void)) 0xb6c590
1: function->fun_symbol->sym_string = {data = "SI_FF_INT", '\0' <repeats 22 times>, count = 9}
(gdb) continue
Continuing.

Breakpoint 1, FUN_evaluate (function=0xb5c6c6d8, node=0xb5c6c494, value=0xb5c6b97c) at ../src/jrd/fun.cpp:1066
1066 UCHAR* temp_ptr = CALL_UDF(function->fun_entrypoint, pUCHAR);
5: function->fun_type = 0
4: function->fun_count = 2
3: function->fun_args = 2
2: function->fun_entrypoint = (int (*)(void)) 0xb6c590
1: function->fun_symbol->sym_string = {data = "SI_FF_INT", '\0' <repeats 22 times>, count = 9}
(gdb) continue
Continuing.

Breakpoint 1, FUN_evaluate (function=0xb5c6c6d8, node=0xb5af281c, value=0xb5abebec) at ../src/jrd/fun.cpp:1066
1066 UCHAR* temp_ptr = CALL_UDF(function->fun_entrypoint, pUCHAR);
5: function->fun_type = 0
4: function->fun_count = 2
3: function->fun_args = 2
2: function->fun_entrypoint = (int (*)(void)) 0xb6c590
1: function->fun_symbol->sym_string = {data = "SI_FF_INT", '\0' <repeats 22 times>, count = 9}
(gdb) continue
Continuing.

Breakpoint 1, FUN_evaluate (function=0xb5ae1608, node=0xb5ae14b8, value=0xb5ad435c) at ../src/jrd/fun.cpp:1066
1066 UCHAR* temp_ptr = CALL_UDF(function->fun_entrypoint, pUCHAR);
5: function->fun_type = 0
4: function->fun_count = 3
3: function->fun_args = 3
2: function->fun_entrypoint = (int (*)(void)) 0x74e8e0
1: function->fun_symbol->sym_string = {data = "SUBSTR", '\0' <repeats 25 times>, count = 6}
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x0074e8e0 in ?? ()
(gdb)

It is looking like the address of the function was overwritten (eg. in FUN_evaluate) or a bug in mod_loader. What's interesting on some computers/clients everything working correctly, and on the same computer when change sequence sql instructions works fine too.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Radek, I don't see problems when you build firebird from sources yourself. But sending core file for such build is useless - it can't be analyzed.
What about bad address of function SUBSTR - are you absolutely sure something bad was not done by SI_FF_INT? Bad UDF library is one of the most common reasons of SEGV in firebird.

Can you prepare _reproducible_ (at least once per 100 runs) test case, including database, SQL script, UDFs - all what I'll need to reproduce a problem?

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

It's well enough to have slightly other gcc version to have incompatible core file. Provided that difefrent linux vendors release gcc with slightly different patches, it's close to unreal to have working core file for binaries, built at another system. I use old RH8 to produce "official" FB binaries, main reason - to let it work with as old glibc version as possible.
Therefore - to produce valid core file the simpliest way is to use SF binaries.

5G is really too big. I hope that problem here is not database itself, and you will be able to make test case. This way seems to be much better then core file in this case - at least in a core file at http://vgakey.net/public/firebird/core.28623.bz2 I've seen completely broken stack (not too strange after passing control to a random location). But (sorry for repeating) this may be also caused by not matching core/binary. If you see something reasonable in backtrace, please send it's output to me privately (pes at kisavto dot ru), and we will try to continue with corefiles too.

@firebird-automations
Copy link
Collaborator Author

Commented by: MikeStar (xsaero00)

Try following procedure in CORE982 to reproduce the bug. I don't know if you can debug it that way though.

The bug is reliably reproduced using PHP interbase functions only. It is just as elusive when other methods are used.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Fixed in both 2.0.1 and HEAD - togeteher with 982.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.0.1 [ 10090 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue relate to CORE982 [ CORE982 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11226 ] => Firebird [ 14657 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: No test => Cannot be tested

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: Cannot be tested => No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants