• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!
  • 2026 staff recruitment is open! Check it out and consider applying!

Programmer Fixing a crash-bug - Stacktrace Report

kito2

kito2

www.masteria.net
Joined
Mar 9, 2009
Messages
3,764
Solutions
1
Reaction score
227
Location
Chile, Santiago
Hello,

I am willing to pay from €20 to €70 aprox in order to fix this bug:

Code: 
(gdb) thread apply all bt full

Thread 4 (Thread 0x7fb786877700 (LWP 5585)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x00007fb788e654dc in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2  0x0000000000591c7d in DatabaseTasks::threadMain() ()
No symbol table info available.
#3  0x0000000000594d1b in void std::_Mem_fn<void (DatabaseTasks::*)()>::operator()<, void>(DatabaseTasks*) const ()
No symbol table info available.
#4  0x0000000000594c6b in void std::_Bind_simple<std::_Mem_fn<void (DatabaseTasks::*)()> (DatabaseTasks*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
No symbol table info available.
#5  0x0000000000594b73 in std::_Bind_simple<std::_Mem_fn<void (DatabaseTasks::*)()> (DatabaseTasks*)>::operator()() ()
No symbol table info available.
#6  0x0000000000594b0c in std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (DatabaseTasks::*)()> (DatabaseTasks*)> >::_M_run() ()
No symbol table info available.
#7  0x00007fb788e68a60 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
---Type <return> to continue, or q <return> to quit---


Code: 
(gdb) bt
#0  0x000000000063bff4 in ScriptEnvironment::addThing(Thing*) ()
#1  0x00000000006941c2 in LuaScriptInterface::luaItemGetUniqueId(lua_State*) ()
#2  0x00007fb789ba861d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#3  0x00007fb789bb390f in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#4  0x00007fb789ba8989 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#5  0x00007fb789bb26ea in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#6  0x00007fb789bb2a18 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#7  0x00007fb789bb3d48 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#8  0x00007fb789ba8989 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#9  0x00007fb789ba7fac in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#10 0x00007fb789ba8bc1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#11 0x00007fb789ba4c9d in lua_pcallk ()
   from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#12 0x000000000063cd4c in LuaScriptInterface::protectedCall(lua_State*, int, int) ()
#13 0x000000000063dad7 in LuaScriptInterface::callFunction(int) ()
#14 0x00000000006a7caa in LuaEnvironment::executeTimerEvent(unsigned int) ()
#15 0x00000000006bc99e in void std::_Mem_fn<void (LuaEnvironment::*)(unsigned int)>::operator()<unsigned int&, void>(LuaEnvironment*, unsigned int&) const ()
#16 0x00000000006b971f in void std::_Bind<std::_Mem_fn<void (LuaEnvironment::*)(unsigned int)> (LuaEnvironment*, unsigned int)>::__call<void, , 0ul, 1ul>(std::tuple<>&&, std::_Index_tuple<0ul, 1ul>) ()
#17 0x00000000006b59ba in void std::_Bind<std::_Mem_fn<void (LuaEnvironment::*)(unsigned int)> (LuaEnvironment*, unsigned int)>::operator()<, void>() ()
---Type <return> to continue, or q <return> to quit---

Interested let me know ;)
 
kito2 said:
Hello,

I am willing to pay from €20 to €70 aprox in order to fix this bug:

Code: 
(gdb) thread apply all bt full

Thread 4 (Thread 0x7fb786877700 (LWP 5585)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x00007fb788e654dc in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2  0x0000000000591c7d in DatabaseTasks::threadMain() ()
No symbol table info available.
#3  0x0000000000594d1b in void std::_Mem_fn<void (DatabaseTasks::*)()>::operator()<, void>(DatabaseTasks*) const ()
No symbol table info available.
#4  0x0000000000594c6b in void std::_Bind_simple<std::_Mem_fn<void (DatabaseTasks::*)()> (DatabaseTasks*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
No symbol table info available.
#5  0x0000000000594b73 in std::_Bind_simple<std::_Mem_fn<void (DatabaseTasks::*)()> (DatabaseTasks*)>::operator()() ()
No symbol table info available.
#6  0x0000000000594b0c in std::thread::_Impl<std::_Bind_simple<std::_Mem_fn<void (DatabaseTasks::*)()> (DatabaseTasks*)> >::_M_run() ()
No symbol table info available.
#7  0x00007fb788e68a60 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
---Type <return> to continue, or q <return> to quit---


Code: 
(gdb) bt
#0  0x000000000063bff4 in ScriptEnvironment::addThing(Thing*) ()
#1  0x00000000006941c2 in LuaScriptInterface::luaItemGetUniqueId(lua_State*) ()
#2  0x00007fb789ba861d in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#3  0x00007fb789bb390f in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#4  0x00007fb789ba8989 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#5  0x00007fb789bb26ea in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#6  0x00007fb789bb2a18 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#7  0x00007fb789bb3d48 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#8  0x00007fb789ba8989 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#9  0x00007fb789ba7fac in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#10 0x00007fb789ba8bc1 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#11 0x00007fb789ba4c9d in lua_pcallk ()
   from /usr/lib/x86_64-linux-gnu/liblua5.2.so.0
#12 0x000000000063cd4c in LuaScriptInterface::protectedCall(lua_State*, int, int) ()
#13 0x000000000063dad7 in LuaScriptInterface::callFunction(int) ()
#14 0x00000000006a7caa in LuaEnvironment::executeTimerEvent(unsigned int) ()
#15 0x00000000006bc99e in void std::_Mem_fn<void (LuaEnvironment::*)(unsigned int)>::operator()<unsigned int&, void>(LuaEnvironment*, unsigned int&) const ()
#16 0x00000000006b971f in void std::_Bind<std::_Mem_fn<void (LuaEnvironment::*)(unsigned int)> (LuaEnvironment*, unsigned int)>::__call<void, , 0ul, 1ul>(std::tuple<>&&, std::_Index_tuple<0ul, 1ul>) ()
#17 0x00000000006b59ba in void std::_Bind<std::_Mem_fn<void (LuaEnvironment::*)(unsigned int)> (LuaEnvironment*, unsigned int)>::operator()<, void>() ()
---Type <return> to continue, or q <return> to quit---

Interested let me know ;)
Click to expand...
The first report is useless because you didn't provide the entire log: "---Type <return> to continue, or q <return> to quit---"

Anyway this is a bug in an addEvent, the only way of fixing it is finding the addEvent that is causing it. You would have to check all addEvent usages on your server. This can take a freaking ton of time depending on how many times it's used in your data pack.
 
Mkalo said:
The first report is useless because you didn't provide the entire log: "---Type <return> to continue, or q <return> to quit---"

Anyway this is a bug in an addEvent, the only way of fixing it is finding the addEvent that is causing it. You would have to check all addEvent usages on your server. This can take a freaking ton of time depending on how many times it's used in your data pack.
Click to expand...

We searched them all and didn't find anything.
 
1. Tell us what sources you use/from what sources you started you project.
2. Type 'bt full', maybe some variables will let us know what is wrong.
3. Compile server with debug info and without so high level of optimization - would be nice to see from what line of what file it jumps in stack.
 
Gesior.pl said:
1. Tell us what sources you use/from what sources you started you project.
2. Type 'bt full', maybe some variables will let us know what is wrong.
3. Compile server with debug info and without so high level of optimization - would be nice to see from what line of what file it jumps in stack.
Click to expand...

Thanks, I am already working with Mkalo. It seems he has fixed it.
 
Back
Top