VOGONS


Weird crash home-compiled debug version 0.73

Topic actions

Reply 20 of 33, by MiniMax

User metadata
Rank Moderator
Rank
Moderator
wd wrote:

A two-character string can't be THAT hard to decrypt.

Actually, the shorter the ciffer-text, the harder it is to decrypt.

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 21 of 33, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Yes but 26*26 should be human-doable with context. So with the gcc
context you're quite directly at an identity encryption.

Reply 22 of 33, by MiniMax

User metadata
Rank Moderator
Rank
Moderator
wd wrote:

Yes but 26*26 should be human-doable with context. So with the gcc context you're quite directly at an identity encryption.

True - except for:

jal wrote:

Mmm, nothing I can go on. I'm not very versed with gdb, (...)

So you and jal don't quite have the same context.

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 23 of 33, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Context switch 😀

Reply 26 of 33, by jal

User metadata
Rank Oldbie
Rank
Oldbie

gcc 4.3.3 (Ubuntu 4.3.3-5ubuntu4), on both systems.

JAL

Reply 27 of 33, by jal

User metadata
Rank Oldbie
Rank
Oldbie

Ok, pretty much totally lost now.

I added a simple LOG_MSG("start MSG_Add"); at the start of the MSG_Add function in messages.cpp, and this is what I get:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77386e0 (LWP 5590)]
0xb7d91969 in _nc_printf_string () from /lib/libncurses.so.5
(gdb) bt
#0 0xb7d91969 in _nc_printf_string () from /lib/libncurses.so.5
#1 0xb7d8d464 in vwprintw () from /lib/libncurses.so.5
#2 0xb7d8d57b in wprintw () from /lib/libncurses.so.5
#3 0x0813688b in DEBUG_ShowMsg (format=0x83835ad "start MSG_Add") at debug_gui.cpp:79
#4 0x083402f8 in MSG_Add (_name=0xac553bc "CONFIG_FULLSCREEN", _val=0xac5536c "Start dosbox directly in fullscreen.") at messages.cpp:48
#5 0x083469bb in Property::Set_help (this=0xac552f8, in=@0xbfc98858) at setup.cpp:223
#6 0x081d2717 in Config_Add_SDL () at sdlmain.cpp:1469
#7 0x081d6f97 in main (argc=Cannot access memory at address 0x0
) at sdlmain.cpp:1655

There must be something seriously fucked up somewhere...

JAL

Reply 28 of 33, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well could be that at this point the ncurses window is not set up so it
crashes badly (though unrelated to the problem). You could set a breakpoint
there though.

Reply 29 of 33, by jal

User metadata
Rank Oldbie
Rank
Oldbie
wd wrote:

Well could be that at this point the ncurses window is not set up so it crashes badly (though unrelated to the problem). You could set a breakpoint there though.

Yeah, could try, but it's getting mightely complex for a simple soul like me 😀. Well, given the time I could probably figure it out, but that's something I unfortunately don't have too much...

JAL

Reply 30 of 33, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

try resizing the terminal manually to something large before starting dosbox

Water flows down the stream
How to ask questions the smart way!

Reply 31 of 33, by jal

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:

try resizing the terminal manually to something large before starting dosbox

Mmm, weird, not just a large size but any size seems to work, as long as the window isn't maximized. When redirecting output to a file it also doesn't crash, btw (although the debugger is not of much use then 😀). Is this some obscure known bug?

JAL

Reply 32 of 33, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

not known, but sometimes a terminal doesn't resize correctly, but if it works with any size as long it isn't maximized than I don't really know

Water flows down the stream
How to ask questions the smart way!

Reply 33 of 33, by jal

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:

not known, but sometimes a terminal doesn't resize correctly, but if it works with any size as long it isn't maximized than I don't really know

Well, at least it seems it isn't really a DOSBox problem, and there's a simple workaround. Thanks for pointing me in the right direction! (And thanks to wd as well, of course.)

JAL