backtrace from gdb

Ok, tried that howto: https://wiki.ubuntu.com/Backtrace
and attached the result.

Hope that's ok.

lovely all call parameters are optimized out. (not really your fault, but if you recompile dosbox could you change the -02 to -O0)

Could you before starting debug nukewar.exe
enter

1core=normal
2cycles=3000

to see if that gives us something more than just a null pointer

Changing the cycles to 3000 - does not change anything.

A new stack trace with -O0 is on it's way.

edit: There it is.

...changing the core being the important part.

btw try this as well.
Open src/hardware/pic.cpp
look for

1(entry->pic_event)(entry->value);

This is line 463
Above that line add this

1        if((entry == NULL) || (entry->pic_event == NULL)) E_Exit("This is really bad");

The core is and was set to normal.

I added the line but the message "This is really bad" did not appear.

edit: Stacktrace with -O0 see last posting

Type "core" before starting the debugger to assure that the value is correctly set.

line 135 is:

1     Bitu blah=(*CallBack_Handlers[ret])();

ret is/might be (according to log) 2332
so that will definetly result in a null pointer.

wd wrote:

Type "core" before starting the debugger to assure that the value is correctly set.

I did and it said "normal" so this options seems always to bet set to normal.

Qbix wrote:

line 135 is: […]
Show full quote

line 135 is:

Copy code to clipboard

1     Bitu blah=(*CallBack_Handlers[ret])();

ret is/might be (according to log) 2332
so that will definetly result in a null pointer.

Tell me if I can help on that (debug messages or sth like that)

Going to sleep now. But that should be trackable with some messages. (at least partially)

Check out prefix_normal.h in the src/cpu/core_normal directory and add
a few LOG_MSG("here at xyz"); calls where return statements are
that don't return CBRET_NONE (that's the debug callbacks and the opcode
0xfe/7) to check which of those is causing it.

Did you mean src/cpu/core_normal/prefix_none.h?

If I do that i get many log lines per second of which are 95%
here at 792
(CASE_W(0xcf) / if (GETFLAG(IF) && PIC_IRQCheck) return CBRET_NONE;)
and 5%
here at 1109
(CASE_B(0xfe) / case 0x07)

The lines before segfault are:

1here at 792
2here at 792
3here at 792
4here at 792
5here at 792
6here at 792
7here at 792
8here at 792
9here at 792
10here at 792
11here at 792
12here at 1109
13here at 792
14here at 1109

Remove all LOG_MSGs you added except for the callback one (0xfe/7).
Change it to print out the instruction pointer, like LOG_MSG("at %x:%x",SegValue(cs),reg_eip);
Run it again and check the cs:ip right before the crash, then start dosbox
again and break into the debugger, look at the code that's currently at
that location.

The last instructions are:

1at f100:464
2at f100:104
3at f100:284
4at f100:44a
5at f100:464
6at c7ff:1d
7at c7ff:1d
8at f100:205
9at c7ff:1d
10at c7ff:1d
11at f100:104
12at f100:284
13at c7ff:1d
14at 100e:1b06

I'm sorry, but I'm new to the dosbox-debugger. My problem is: I'm pressing F5 at program start because the game startup is of no interest for me (and the crash occurs later).
But in the game I found no way to return to the debugger.

According to this posting: Guide to the DOSBox debugger
the keys 1-5 would be helpful, but they don't seem to work in 0.73.

Can you give me a hint?

try f10

That doesn't work. Even if I step over the instructions from start, the game takes over control as soon as some files are loaded and I have no chance to return to the debugger again.

Besides, the crash occurs immediately after a mouse click, so I should be able to do some input and using the debugger.

there is f11 as well,
but
you could do in the debugger of dosbox:
bp 100e:1b06
f5
to see if it breaks before the crash and to see what kind of code is there. If there is real rubish there then we can as next step let dosbox create a (back) log of the instructions leading to there

It doesnt' break.

I tried with F11, but somehow it seems that I'm trapped in an infinite loop!?

I don't think that there are rubbish instructions, because the game runs fine without debugger.
What could be different for the program if run by the debugger?

edit: I also tried breakpoints at f100:284 and c7ff:1d. But since the crash occurs directly after a click and I can't properly do input while the debugger is active I had no luck to get to the right position.