#548 64-bit binary build crashes while starting the dosdebug.

[Oleg Belov]

64-bit binary build crashes while starting the dosdebug.

ERROR: Accessing reserved memory at 4000a87f60
Maybe a null segment register
ERROR: cpu exception in dosemu code outside of VM86()!
trapno: 0x0e errorcode: 0x00000004 cr2: 0x4000a87f60
eip: 0x004d7439 esp: 0x7fffd3c57040 eflags: 0x00010206
cs: 0x0033 ds: 0x0000 es: 0x0000 ss: 0x002b
ERROR: Please report the contents of ~/.dosemu/boot.log at
http://sourceforge.net/tracker/?atid=457447&group_id=49784&func=browse
It would be even more helpful if would recompile DOSEMU and reproduce this
bug with "debug on" in compiletime-settings.
Page fault: read instruction to linear address: 0x4000a87f60

---

It seems that when there are no symbols at all the statement
addrmax = symbol_table[last_symbol-1].addr;
at the end of
static void mhp_rmapfile(int argc, char *argv[])
, mhpdbgc.c:415, reads out of page.

IMHO it will be better to protect this and the last statement using

mhp_printf("%d symbol(s) processed\n", last_symbol);
if (last_symbol) {
addrmax = symbol_table[last_symbol-1].addr;
mhp_printf("highest address %08lx(%s)\n", addrmax, getname(addrmax));
} else {
??? what value for addrmax may be safe?
}

P.S. This problem arises in design of encapsulation (by means of remote control through debugger interface) of dosemu in Ruby class. This encapsulation is actually used by our team for running of very old scientific programs written for DOS with Borland's text mode GUI (and with forgotten sources) in Ruby and Ruby on rails environment. It is a very specific job, and I'm not sure that this code is interesting for anybody, but I can publish this solution here or on Rubyforge on demand. We use a hand-made patch for this problem just by replacing of word 'rmapfile' located between 'log on' and 'log off' by spaces in binary file.

[Stas Sergeev]

Thanks for your analysis, fix applied.
I don't think you should use debugger
interface for remote control. See userhook.c
for the remote control interface.
Unfortunately, this interface is so old
that even I have never used it. :)

[Oleg Belov]

Thank you! I use debugger interface because I need to send not only characters but also scan codes just to keyboard buffer. Moreover, I need to grab data from emulated video memory because the target program uses it directly. I don't know an other method to do it except the debugger interface. For whom it may interest I attach my code (not well documented, sorry).

[Stas Sergeev]

Thank you! I use debugger interface because I need to send
not only characters but also scan codes just to keyboard buffer.

This should work properly.
When some char goes to dosemu, it finds
its scan code (or a sequence of scan codes)
and makes it available through the keyboard
port. bios then puts the char to the buffer.
What is the problem with this?

grab data from emulated video memory because the target
program uses it directly.

Is it a text data or graphical data?
In case of the text data there should be better
ways than the debugger peeks and pokes.
For example you can use "screen" (or maybe also
"tmux", I tried only with screen) that will keep
an image of a dosemu's text screen, and will allow
you to access it in any way you want.
When you run something (like dosemu) under "screen",
"screen" interprets all the terminal control sequences
and builds the internal image from that. Looks like
this is what you want.

For whom it may interest I attach my code (not well documented, sorry).

I am not sure it can be useful without an app
that uses it. And in any case, I prefer some
well-defined protocols, not the debugger pokes.
"screen" uses a well-defined protocols to achieve
the same thing you do with debugger peeks, unless
I am missing the point.