VOGONS

Search

Common searches

CPU_IRET function issue

Topic actions

First post, by afactorydowntown

Posted on 
User metadata
Rank Newbie
Rank
Newbie

Hey guys,

This is my first post to the forum because I am seeking help with an issue I am having running some software on DOSBox version 0.74 (built from source) in Ubuntu 64-bit 12.04.2 LTS.

Every 10-15 executions, DOSBox will crash shortly after start-up. I used "gdb" to track down the error and it always seems to stem from CPU_IRET function, but the actual exception message changes. I suspect it has to do with a bad pointer or something where it just retrieves bad data due to the varying failure locations. Here are 3 example backtraces from "gdb":

#0 0x00007ffff60c0425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff60c3b8b in abort () from /lib/x86_64-linu […]
Show full quote

#0 0x00007ffff60c0425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff60c3b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6a1369d in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6a11846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6a11873 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6a1196e in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00000000005bef92 in E_Exit (format=<optimized out>) at support.cpp:184
#7 0x00000000004127ee in CPU_SetSegGeneral (seg=ss, value=985) at cpu.cpp:1992
#8 0x0000000000412f7e in CPU_SwitchTask (new_tss_selector=312,
tstype=TSwitch_IRET, old_eip=18) at cpu.cpp:553
#9 0x00000000004153fb in CPU_IRET (use32=false, oldeip=<optimized out>)
at cpu.cpp:870
#10 0x00007fffedf72634 in ?? ()
#11 0x00007fffffffab78 in ?? ()
#12 0x00007fffedf6d043 in ?? ()
#13 0x0000000000081211 in ?? ()
#14 0x000000000047c5f6 in CPU_Core_Dynrec_Run () at core_dynrec.cpp:233
#15 0x0000000000408cf7 in Normal_Loop () at dosbox.cpp:132
#16 0x000000000040958e in DOSBOX_RunMachine () at dosbox.cpp:244
#17 0x000000000040faf9 in CALLBACK_RunRealInt (intnum=<optimized out>)
at callback.cpp:106
#18 0x00000000005c7d79 in DOS_Shell::Execute (this=<optimized out>,
name=<optimized out>, args=<optimized out>) at shell_misc.cpp:492
#19 0x00000000005c58d3 in DOS_Shell::DoCommand (this=0x3708e80,
line=0x7fffffffce5b "") at shell_cmds.cpp:153
#20 0x00000000005bf9de in DOS_Shell::ParseLine (this=0x3708e80,
line=0x7fffffffce50 "CODE.EXE") at shell.cpp:251
#21 0x00000000005bff32 in DOS_Shell::Run (this=0x3708e80) at shell.cpp:324
#22 0x00000000005c091f in SHELL_Init () at shell.cpp:654
#23 0x0000000000408107 in main (argc=<optimized out>, argv=<optimized out>)
at sdlmain.cpp:1880

#0 0x00007ffff60c0425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff60c3b8b in abort () from /lib/x86_64-linu […]
Show full quote

#0 0x00007ffff60c0425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff60c3b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6a1369d in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6a11846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6a11873 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6a1196e in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00000000005befb2 in E_Exit (format=<optimized out>) at support.cpp:184
#7 0x00000000004135b7 in CPU_SwitchTask (new_tss_selector=0,
tstype=TSwitch_IRET, old_eip=18) at cpu.cpp:351
#8 0x000000000041541b in CPU_IRET (use32=false, oldeip=<optimized out>)
at cpu.cpp:870
#9 0x00007fffedf6ee84 in ?? ()
#10 0x00007fffffffab78 in ?? ()
#11 0x00007fffedf6d043 in ?? ()
#12 0x0000000000081211 in ?? ()
#13 0x000000000047c616 in CPU_Core_Dynrec_Run () at core_dynrec.cpp:233
#14 0x0000000000408cf7 in Normal_Loop () at dosbox.cpp:132
#15 0x000000000040958e in DOSBOX_RunMachine () at dosbox.cpp:244
#16 0x000000000040faf9 in CALLBACK_RunRealInt (intnum=<optimized out>)
at callback.cpp:106
#17 0x00000000005c7d99 in DOS_Shell::Execute (this=<optimized out>,
name=<optimized out>, args=<optimized out>) at shell_misc.cpp:492
#18 0x00000000005c58f3 in DOS_Shell::DoCommand (this=0x3708e60,
line=0x7fffffffce5b "") at shell_cmds.cpp:153
#19 0x00000000005bf9fe in DOS_Shell::ParseLine (this=0x3708e60,
line=0x7fffffffce50 "CODE.EXE") at shell.cpp:251
#20 0x00000000005bff52 in DOS_Shell::Run (this=0x3708e60) at shell.cpp:324
#21 0x00000000005c093f in SHELL_Init () at shell.cpp:654
#22 0x0000000000408107 in main (argc=<optimized out>, argv=<optimized out>)
at sdlmain.cpp:1880

#0 0x00007ffff60c0425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff60c3b8b in abort () from /lib/x86_64-linu […]
Show full quote

#0 0x00007ffff60c0425 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff60c3b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6a1369d in __gnu_cxx::__verbose_terminate_handler() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff6a11846 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff6a11873 in std::terminate() ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff6a1196e in __cxa_throw ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00000000005befb2 in E_Exit (format=<optimized out>) at support.cpp:184
#7 0x0000000000412f52 in CPU_SwitchTask (new_tss_selector=312,
tstype=TSwitch_IRET, old_eip=18) at cpu.cpp:532
#8 0x000000000041541b in CPU_IRET (use32=false, oldeip=<optimized out>)
at cpu.cpp:870
#9 0x00007fffedf6f2f4 in ?? ()
#10 0x00007fffffffab78 in ?? ()
#11 0x00007fffedf6d043 in ?? ()
#12 0x0000000000081211 in ?? ()
#13 0x000000000047c616 in CPU_Core_Dynrec_Run () at core_dynrec.cpp:233
#14 0x0000000000408cf7 in Normal_Loop () at dosbox.cpp:132
#15 0x000000000040958e in DOSBOX_RunMachine () at dosbox.cpp:244
#16 0x000000000040faf9 in CALLBACK_RunRealInt (intnum=<optimized out>)
at callback.cpp:106
#17 0x00000000005c7d99 in DOS_Shell::Execute (this=<optimized out>,
name=<optimized out>, args=<optimized out>) at shell_misc.cpp:492
#18 0x00000000005c58f3 in DOS_Shell::DoCommand (this=0x3708e80,
line=0x7fffffffce5b "") at shell_cmds.cpp:153
#19 0x00000000005bf9fe in DOS_Shell::ParseLine (this=0x3708e80,
line=0x7fffffffce50 "CODE.EXE") at shell.cpp:251
#20 0x00000000005bff52 in DOS_Shell::Run (this=0x3708e80) at shell.cpp:324
#21 0x00000000005c093f in SHELL_Init () at shell.cpp:654
#22 0x0000000000408107 in main (argc=<optimized out>, argv=<optimized out>)
at sdlmain.cpp:1880

Anyone have an idea what the problem may be? Any thoughts at all would be greatly appreciated. I don't really know the intricacies of the DOSBox emulation so if there is anything you want me to try out and debug, please let me know.

Thank you,

-Corey

Reply 1 of 11, by Dominus

Posted on 
User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Does it crash right away when you enter
Core dynamic
?
If yes, try SVN of DOSBox, well, you should try that anyway to see whether your problem has been fixed in the years since 0.74

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 2 of 11, by Qbix

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

Those crashes are with the dynrec core it seems. Does it happen with using the default settings as well ?

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

Reply 3 of 11, by afactorydowntown

Posted on 
User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

Those crashes are with the dynrec core it seems. Does it happen with using the default settings as well ?

It seems like the C_DYNREC define is set to 1 during the ./configure step, so that's why it was enabled. I tried using the x86 CPU core and then the normal one, and I wasn't seeing any difference in results. I even tried to remove the -O2 compilation optimization, but that didn't seem to help either.

I ran this application in a Windows compilation of DOSBox with no problems, but the Linux version is much more unreliable. See the attached image of the task switching that occurs in the Windows version consistently. However, in the Linux version, sometimes I get the CPU_Interrupt 1st or 2nd. When it happens first, that is when the system crashes:

CPU_JMP:1106 Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7206 Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7297 Task CPL 0 CS:4 […]
Show full quote

CPU_JMP:1106
Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7206
Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7297
Task CPL 0 CS:44 IP:0 SS:84 SP:0 eflags 202
CPU_JMP:1106
Task CPL 0 CS:44 IP:BD SS:84 SP:0 eflags 212
Task CPL 0 CS:44 IP:BD SS:84 SP:0 eflags 212
Task CPL 0 CS:14 IP:0 SS:24 SP:0 eflags 202
CPU_Interrupt:795
Task CPL 0 CS:14 IP:1B SS:24 SP:0 eflags 297
Task CPL 0 CS:14 IP:1B SS:24 SP:0 eflags 297
Task CPL 0 CS:1C IP:0 SS:64 SP:0 eflags 4002
CPU_IRET:872
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4002
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4046
Task CPL 0 CS:14 IP:1B SS:24 SP:0 eflags 297

CPU_JMP:1106 Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7206 Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7297 Task CPL 0 CS:4 […]
Show full quote

CPU_JMP:1106
Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7206
Task CPL 0 CS:14 IP:20A9 SS:3D9 SP:A0 eflags 7297
Task CPL 0 CS:44 IP:0 SS:84 SP:0 eflags 202
CPU_Interrupt:795
Task CPL 0 CS:44 IP:98 SS:84 SP:0 eflags 212
Task CPL 0 CS:44 IP:98 SS:84 SP:0 eflags 212
Task CPL 0 CS:1C IP:0 SS:64 SP:0 eflags 4002
CPU_IRET:872
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4002
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4046
Task CPL 0 CS:44 IP:98 SS:84 SP:0 eflags 212
CPU_JMP:1106
Task CPL 0 CS:44 IP:BD SS:84 SP:0 eflags 212
Task CPL 0 CS:44 IP:BD SS:84 SP:0 eflags 212
Task CPL 0 CS:14 IP:0 SS:24 SP:0 eflags 202

CPU_Interrupt:795 Task CPL 0 CS:14 IP:2272 SS:3D9 SP:9C eflags 7297 Task CPL 0 CS:14 IP:2272 SS:3D9 SP:9C eflags 7297 Task CPL 0 […]
Show full quote

CPU_Interrupt:795
Task CPL 0 CS:14 IP:2272 SS:3D9 SP:9C eflags 7297
Task CPL 0 CS:14 IP:2272 SS:3D9 SP:9C eflags 7297
Task CPL 0 CS:1C IP:0 SS:64 SP:0 eflags 4002
CPU_IRET:872
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4002
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4046
terminate called after throwing an instance of 'char*'

So, as you can see, after that last example, when the Interrupt happens before anything else, the system crashes.

For understanding the print-outs, there are lines that are equivalent to "__FUNCTION__:__LINE__" (where __LINE__ is right before the CPU_SwitchTask() call), and then other lines that start with "Task" are...

LOG_MSG("Task CPL %X CS:%X IP:%X SS:%X SP:%X eflags %x",cpu.cpl,SegValue(cs),reg_eip,SegValue(ss),reg_esp,reg_flags);

...uncommented from the bottom of the CPU_SwitchTask function and then added to the first line and after the FillFlags() function. So, basically it looks like this:

bool CPU_SwitchTask(Bitu new_tss_selector,TSwitchType tstype,Bitu old_eip) {
	LOG_MSG("Task CPL %X CS:%X IP:%X SS:%X SP:%X eflags %x",cpu.cpl,SegValue(cs),reg_eip,SegValue(ss),reg_esp,reg_flags);
	FillFlags();
	LOG_MSG("Task CPL %X CS:%X IP:%X SS:%X SP:%X eflags %x",cpu.cpl,SegValue(cs),reg_eip,SegValue(ss),reg_esp,reg_flags);

...

	LOG_MSG("Task CPL %X CS:%X IP:%X SS:%X SP:%X eflags %x",cpu.cpl,SegValue(cs),reg_eip,SegValue(ss),reg_esp,reg_flags);
}

Any ideas?

I didn't get a chance to test using the latest copy from SVN, yet. Do you think this issue has been fixed?

-Corey

Attachments

  • Untitled.png
    Filename
    Untitled.png
    File size
    14.61 KiB
    Views
    1963 views
    File comment
    Windows consistently
    File license
    Fair use/fair dealing exception

Reply 4 of 11, by Qbix

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

There have been some changes that could influence the order in which certain bytes were read, depending on the compiler used. Although I don't know if that has anything to you with your problem.

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

Reply 5 of 11, by afactorydowntown

Posted on 
User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

There have been some changes that could influence the order in which certain bytes were read, depending on the compiler used. Although I don't know if that has anything to you with your problem.

I guess you are saying that I should try the latest SVN version to see if there are any differences? I can give that a try.

Reply 6 of 11, by afactorydowntown

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I updated to the latest in SVN and I still get the same issue. The Jumps and Interrupts don't reliably happen in the same order on each execution, but I'm not sure if it matters. All I know is that if the Interrupt happens first, then the IRET fails.

Reply 7 of 11, by afactorydowntown

Posted on 
User metadata
Rank Newbie
Rank
Newbie

I decided to prevent the Exceptions from being thrown to see what happens and if I would get some useful information. Unfortunately, I am not very familiar with all of the registers and stuff. It does look like something is a bit off with the SP (stack pointer?). Does this help any of you guys understand what the issue could be? See below:

CPU_Interrupt:795 Task CPL 0 CS:14 IP:3A83 SS:3D9 SP:9A eflags 7287 Task CPL 0 CS:14 IP:3A83 SS:3D9 SP:9A eflags 7287 Task CPL 0 […]
Show full quote

CPU_Interrupt:795
Task CPL 0 CS:14 IP:3A83 SS:3D9 SP:9A eflags 7287
Task CPL 0 CS:14 IP:3A83 SS:3D9 SP:9A eflags 7287
Task CPL 0 CS:1C IP:0 SS:64 SP:0 eflags 4002
CPU_IRET:872
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4002
Task CPL 0 CS:1C IP:11 SS:64 SP:0 eflags 4046
Task CPL 0 CS:14 IP:3A83 SS:64 SP:9A eflags 7287
CPU_IRET:872
Task CPL 0 CS:14 IP:2A2 SS:64 SP:548 eflags 7256
Task CPL 0 CS:14 IP:2A2 SS:64 SP:548 eflags 7202
Task CPL 0 CS:14 IP:F000FEA5 SS:64 SP:F0001080 eflags 6987
Illegal read from f00ab6d5, CS:IP 14:f000fea5
Illegal read from f00ab6d6, CS:IP 14:f000fea5
CPU_CALL:1353
Task CPL 0 CS:998 IP:124 SS:64 SP:F000107A eflags 2002
Task CPL 0 CS:998 IP:124 SS:64 SP:F000107A eflags 2002
Task CPL 0 CS:14 IP:0 SS:5C SP:F0000000 eflags 4202
CPU_JMP:1106
Task CPL 0 CS:14 IP:88 SS:5C SP:F0000000 eflags 4292
Task CPL 0 CS:14 IP:88 SS:5C SP:F0000000 eflags 4292
Task CPL 0 CS:14 IP:0 SS:24 SP:F0000000 eflags 202

Reply 11 of 11, by Qbix

Posted on 
User metadata
Rank DOSBox Author
Rank
DOSBox Author

You can try compiling in debugger support in dosbox, because it will enable more types of cpu exceptions (as bonus)

./configure --enable-debug

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

Go to top of page Go to top of page
Back to DOSBox Development
Close window
Close window