Page 1 of 1

Stacktrace autoprint

PostPosted: 18 Jun 2014, 00:43
by paul424
Bertram and others , could you try branch 'paul424-stacktrace' .
I put the code to print the stacktrace, though it might need some slight modifications ; just try to crash the game ( like starttileculling )
I wonder whether it can be build on WIndows as well . Please test and merge into , if it works fine ...

Re: Stacktrace autoprint

PostPosted: 19 Jun 2014, 20:31
by Bertram
Hi Paul, :)

First of all, thank you for commiting this in a separate branch. :)

Here are my first comments on the stacktrace 2 first commits.
The code style looks fine but there are two things you should do:
- First of all, you should move the code and includes within a separate cpp file.
- Secondly, for unsupported platforms, such as osx, the code should disable itself instead of provoking an error.

- The whole indentation of this code block below is broken.
- This block should be put within a function and called from there. You could then simply not call the function when the platform isn't supported.
struct sigaction sigact; <-- The word struct shouldn't be here.
+
+sigact.sa_sigaction = crit_err_hdlr;
+sigact.sa_flags = SA_RESTART | SA_SIGINFO;
+
+if (sigaction(SIGSEGV, &sigact, (struct sigaction *)NULL) != 0)
+{
+fprintf(stderr, "error setting signal handler for %d (%s)\n",
+ SIGSEGV, strsignal(SIGSEGV));
+
+exit(EXIT_FAILURE);
+}

Could you fix all that?

thanks

Re: Stacktrace autoprint

PostPosted: 19 Jun 2014, 22:09
by Dm3d
Hello paul, I've tried this build on linux mint 17 and I managed to crash the game by enabling culling, holding one of the rotate camera buttons down(E) and moving the camera around rapidly for a short period of time.

I don't have much experience with this :oops:, so bear with me. I ran the .bin in gdb and this was the output(I had to hand copy it since I lose interface control inside game).
{l Code}: {l Select All Code}
1
0
1
3
1
3
1

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5e90508 in std::basic_string <char, std::char_traits<char>,
 std::allocator<char> >::basic_string (std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6


I'm not sure if this is the information you're looking for.

Re: Stacktrace autoprint

PostPosted: 19 Jun 2014, 23:07
by paul424
Well , with my new branch you should get similar result, except you would get the WHOLE STACKTRACE , not only the first frame ( that is the instnce of the function which blundered the program) . Heh , are you any good in Computer Science ?
Ahh you run GDB ... now you would get a detailed stacktrace everytime the game crashes, isn't that nice ?
Well I knew about this error. Sorry for large delays, we have political earthquake in Poland, nobody knows whether to cry of laugh ...

Re: Stacktrace autoprint

PostPosted: 20 Jun 2014, 04:06
by Dm3d
Oh, so that information was from gdb itself? how do you get the stack trace from your build directly?
paul424 {l Wrote}:Heh , are you any good in Computer Science ?

I'm kind of a beginner at it. I can hack together various libraries to make a very simplistic application. but I don't have a good enough grasp on the architectural and theory side of it to really go beyond that.
paul424 {l Wrote}:Ahh you run GDB ... now you would get a detailed stacktrace everytime the game crashes, isn't that nice ?

Definitely makes life a lot easier. sadly,I've never really been in a situation where I had to actually use it... so it's still mostly a mystery to me.
paul424 {l Wrote}:Sorry for large delays, we have political earthquake in Poland, nobody knows whether to cry of laugh ...

No worries, it's fine.

Re: Stacktrace autoprint

PostPosted: 20 Jun 2014, 09:10
by Bertram
Sorry for large delays, we have political earthquake in Poland, nobody knows whether to cry of laugh ...

I'm very sorry to hear that, Paul. I hope things will sort out for your country soon.

Re: Stacktrace autoprint

PostPosted: 21 Jun 2014, 23:12
by paul424
All done , what you asked for , except Apple's main CPU is for a long time Intel's CPU : ( speaking of OSX platform ) :
http://www.pcworld.co.uk/gbuk/desktop-pc-monitors/desktop-pcs/apple-desktops/706_7027_70027_xx_xx/xx-criteria.html

So this code should just work on all CPU's right ? Well we lack IA_64 (italianum )

Re: Stacktrace autoprint

PostPosted: 22 Jun 2014, 12:09
by Bertram
Indeed, it looks better. :)

Yet you forgot the new files copyright headers. ;)
I've got a little readability change related to your patch in mind. I think you can merge (and add copyright headers if you have the time an will),
and I try the thing I have in mind based on this.

Re: Stacktrace autoprint

PostPosted: 22 Jun 2014, 13:58
by oln
The code looks like it's from here. Doesn't give any license info though (though stackoverflow TOU says things posted are CC-BY-SA).

Re: Stacktrace autoprint

PostPosted: 22 Jun 2014, 14:09
by paul424
Yeap , it is from there , if he does not give license , then what should I do , oln ?

Re: Stacktrace autoprint

PostPosted: 22 Jun 2014, 14:20
by charlie
CC-by-SA apparently. TBH though, it's not an issue. This is public domain stuff. Nobody will give a damn if you copy/paste from SO answers. I know that might sound flippant, but this is an entirely different scenario to copying somebody's project code. People who post answers on SO do so in order to help everybody. They don't do it to hold you to some attribution clause. 99% of posters won't even know about this CC-by-SA.

http://meta.stackexchange.com/questions ... ny-license

Re: Stacktrace autoprint

PostPosted: 22 Jun 2014, 18:37
by paul424
Bertram : ok done

Re: Stacktrace autoprint

PostPosted: 22 Jun 2014, 21:18
by Bertram
Cool.

Can you merge it back to development?

EDIT: Could you also have a look at my repo and tell me whether I can merge the latest stuff?

Regards,

Re: Stacktrace autoprint

PostPosted: 23 Jun 2014, 10:44
by MCMic
@Dm3d: With gdb you can use "bt" or "backtrace" to see the call trace after a crash (but on my computer OD does not give me my keyboard back so I’m stuck…)

Re: Stacktrace autoprint

PostPosted: 23 Jun 2014, 11:33
by Bertram
Ah yes, we need to add the cegui parameter we talked about before.
Need to find that back.

Re: Stacktrace autoprint

PostPosted: 23 Jun 2014, 19:26
by paul424
"Ah yes, we need to add the cegui parameter we talked about before.
Need to find that back."

Ehem which cegui parameter ?

Re: Stacktrace autoprint

PostPosted: 23 Jun 2014, 21:47
by Bertram
Ehem which cegui parameter ?


Found it back:
https://github.com/Bertram25/OpenDungeo ... d5bb1e8751
With this patch, you can still play the game but use gdb freely also. This will ease OD development a lot.

Regards,

Re: Stacktrace autoprint

PostPosted: 23 Jun 2014, 22:17
by paul424
My first and foremost intention was to have always stacktrace behind our eyes after the game crash, whatever the user or programmer is runnning OD , so there is some info of what went wrong , instead of the >> black box's << cog wheels got stuck ...

Re: Stacktrace autoprint

PostPosted: 23 Jun 2014, 23:24
by Bertram
My first and foremost intention was to have always stacktrace behind our eyes after the game crash, whatever the user or programmer is runnning OD , so there is some info of what went wrong , instead of the >> black box's << cog wheels got stuck ...

Sure, that feature isn't incompatible with the other, don't worry.

Re: Stacktrace autoprint

PostPosted: 26 Jun 2014, 01:59
by Dm3d
MCMic {l Wrote}:@Dm3d: With gdb you can use "bt" or "backtrace" to see the call trace after a crash (but on my computer OD does not give me my keyboard back so I’m stuck…)


ah, thanks for the tip! that was the same problem I had. if it crashed the only way I could regain control was to close terminal window.

Bertram {l Wrote}:
Ehem which cegui parameter ?


Found it back:
https://github.com/Bertram25/OpenDungeo ... d5bb1e8751
With this patch, you can still play the game but use gdb freely also. This will ease OD development a lot.

Regards,


Thanks Bertram, that did the trick! :D

Re: Stacktrace autoprint

PostPosted: 26 Jun 2014, 08:59
by Bertram
You're welcome. :)

I had to revert that patch to prevent breaking MCmic's environment, but you can change the value back to false anytime when willing to debug.

Regards,