Re: Dosemu 1.1.99.1 segfaults

Re: Dosemu 1.1.99.1 segfaults

[Stas Sergeev]

Hello.

Ged Haywood wrote:
> I compiled dosemu with debugging enabled, ran 'dosemu -D+a -o debug'
-D9+M might be sufficient.

> ERROR: CS selector invalid: 0x0073, type=0 np=1
> leavedos(36|0x24) called - shutting down
> ERROR: leavedos() called from within a signal context!
Doesn't look like a segfault actually,
just a termination due to a failed sanity
check.

> but I thought you might want
> to know that things in the dosemu/DPMI world still need some attention.
That's true. I would suspect my DPMI 1.0
capabilities patches, but who knows...

> If you want any more information please let me know.
Please open the bug report at BTS at first
so that the problem won't escape.
-D9+M log would be nice, but some test-case
would be even better (attach either to the
bug report).
And if you can do a binary search in CVS
and locate the offending patch - that would
be really great.

Re: Dosemu 1.1.99.1 segfaults

[Ged Haywood]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1528 bytes --]

Hi Stas,

On Wed, 29 Oct 2003, Stas Sergeev wrote:

> -D9+M might be sufficient.

Attached.

> > ERROR: CS selector invalid: 0x0073, type=0 np=1
> > leavedos(36|0x24) called - shutting down
> > ERROR: leavedos() called from within a signal context!
> Doesn't look like a segfault actually, just
> a termination due to a failed sanity check.

When I say segfault I mean that Linux says 'segfault' and suddenly I'm
not looking at a dosemu screen any more, I'm  back to the Linux shell.
So I guess I mean segfault.  :)

> Please open the bug report at BTS at first
> so that the problem won't escape.

Done.

> -D9+M log would be nice, but some test-case would be even better
> (attach either to the bug report).

I haven't attached anything to the bug report.  It took nearly an hour
to get the report in there so at that point I quit while I was ahead.

It's very easy to reproduce the segfault, all you have to do is start
the compiler and dosemu crashes.  If you want a copy of the executable
I'm sure it's OK for me to send it.  I don't think the copyright owner
has been dead for 50 years but I don't think he's going to sue me. :)
It's about 170kB so I haven't attached it to this message.

> And if you can do a binary search in CVS and locate the offending
> patch - that would be really great.

I have no idea what I'd be looking for.  If you can give me a clue I
might be able to have a look, but I'm afraid I can't afford to spend
hours wandering around in the source tree looking for a needle in a
haystack.

73,
Ged.

[-- Attachment #2: debug.bz2 --]
[-- Type: APPLICATION/x-bzip2, Size: 2997 bytes --]

Re: Dosemu 1.1.99.1 segfaults

[Stas Sergeev]

Hello.

Ged Haywood wrote:
> the same version of DOS (6.22) running natively.  This seems to me to be
> a surprisingly big difference and I wonder if it means something to you.
> If you want more information can investigate more easily when I'm back
Feel free to produce a -D9+M log for the
case where it gets a stack fault. I have
no idea why this can happen. DPMI server
puts a lot of stuff on a stack, although
not on a client's stack in most cases,
but rather on a "locked" stack. But I don't
think it is some bug.

> If there's anything else you'd like me to try out on dosemu 1.3.0.0
> while I have it running on Athlon/VIA/kernel 2.6.0 please let me know.
See if the Release-1_2 branch also has
the fix you require to compile your
program. There are some patches in HEAD
that are not in Release-1_2. Make sure
they are not important for your stuff,
otherwise there is a risk you will miss
some functionality in 1.2.

Re: Dosemu 1.1.99.1 segfaults

[Ged Haywood]

Hi Stas,

On Sat, 1 Nov 2003, Stas Sergeev wrote:

> Ged Haywood wrote:
> > the same version of DOS (6.22) running natively.  This seems to me to be
> > a surprisingly big difference and I wonder if it means something to you.

> Feel free to produce a -D9+M log for the case where it gets a stack fault.

OK.  Just to be clear - this is a DOS stack fault only, DOSEMU runs
fine and doesn't fail when the DOS C++ compiler runs out of stack.

> See if the Release-1_2 branch also has the fix you require to
> compile your program.

Will do.  It won't be until later in the week, I'll be travelling for
a couple of days now.

73,
Ged.

Re: Dosemu 1.1.99.1 segfaults

[Stas Sergeev]

Hello.

Ged Haywood wrote:
>> What kernel are you using? Some kind of 2.6? 
>  2.6.0-test5
Dumb question actually, it was written
in the beginning of the log...

>> You have to upgrade your dosemu in that case.
>  Oh dear.  Upgrade to what?
To CVS HEAD just as usual. It is known
to be a good practice to update to CVS
HEAD before reporting any bugs. That
really helps and not only with dosemu.

> Does it say that in the docs?
> If so, where?  I haven't found anything about kernel versions
> in the docs
But dosemu tells you every time you
start it:
---
Please test against a recent version before reporting bugs and problems.
---
Most people don't understand the importance
of that note. But probably now it must be
adjusted to reflect the fact that there is a
CVS in use.

> If you will please tell me where or how to find the fix, I'll cease
> troubling you...
CVS repository of dosemu is the place where
the fixes are now lingering.

Re: Dosemu 1.1.99.1 segfaults

[Ged Haywood]

Hi Stas,

On Thu, 30 Oct 2003, Stas Sergeev wrote:

> > Does it say that in the docs?
> > If so, where?  I haven't found anything about kernel versions
> > in the docs
> But dosemu tells you every time you
> start it:
> ---
> Please test against a recent version before reporting bugs and problems.
> ---
> Most people don't understand the importance of that note. But probably
> now it must be adjusted to reflect the fact that there is a CVS in use.

Here's a patch for the docs...

- Please test against a recent version before reporting bugs and problems.
+ Please test against a very very very recent version before reporting bugs and problems.

:)

I'll try CVS next.

73,
Ged.

Re: Dosemu 1.1.99.1 segfaults

[Bart Oldeman]

On Thu, 30 Oct 2003, Ged Haywood wrote:

> On Thu, 30 Oct 2003, Stas Sergeev wrote:
>
> > > Does it say that in the docs?
> > > If so, where?  I haven't found anything about kernel versions
> > > in the docs
> > But dosemu tells you every time you
> > start it:
> > ---
> > Please test against a recent version before reporting bugs and problems.
> > ---
> > Most people don't understand the importance of that note. But probably
> > now it must be adjusted to reflect the fact that there is a CVS in use.
>
> Here's a patch for the docs...
>
> - Please test against a recent version before reporting bugs and problems.
> + Please test against a very very very recent version before reporting bugs and problems.
>
> :)
>
> I'll try CVS next.

it's more that the combination of a (still somewhat) bleeding edge kernel
with dosemu has always been tricky at times, because dosemu by its very
nature intimately interfaces with the kernel.

So I expect people who are brave enough to try 2.6 test kernels to be
brave enough to search the mailing list archives for any clues about
things that worked in 2.4.x and don't work in 2.6 :)

Bart

Re: Dosemu 1.1.99.1 segfaults

[Ged Haywood]

Hi Bart,

On Thu, 30 Oct 2003, Bart Oldeman wrote:

> people who are brave enough to try 2.6 test kernels

Nothing brave about it: if I plug in a USB device with kernel 2.4.xx
on my Athlon 1300 the kernel crashes, so I have to use 2.6 to get the
photographs out of my camera... :(

Ged.

Re: Dosemu 1.1.99.1 segfaults

[Ged Haywood]

Hi Bart, Stas,

On Thu, 30 Oct 2003, Ged Haywood wrote:

> I'll try CVS next.

Congratulations!  Works fine with CVS.
I've been trying to compile this app under DOSEMU literally for years.
Finally it's done.  Thanks guys.  Great stuff, now I can throw a DOS
box away (well, turn it into a firewall or something:).

Here's the app compiled and zipped this morning under DOSEMU:
======================================================================
C:\SOS>pu -v sosppx4

PKUNZIP (R)    FAST!    Extract Utility    Version 2.04g  02-01-93
Copr. 1989-1993 PKWARE Inc. All Rights Reserved. Registered version
PKUNZIP Reg. U.S. Pat. and Tm. Off.

= 80486 CPU detected.
= XMS version 3.00 detected.
= DPMI verrsion 0.90 detected.

Searching ZIP: SOSPPX4.ZIP

 Length  Method   Size  Ratio   Date    Time    CRC-32  Attr  Name
 ------  ------   ----- -----   ----    ----   -------- ----  ----
 583545  DeflatN 273217  54%  10-31-03  14:00  a1598864 --w-  SOSPPX4.EXE
 ------          ------  ---                                  -------
 583545          273217  54%                                        1
======================================================================
and here's one I prepared earlier:

hurricane:$ >>> unzip -lv /mnt/hdb2/sos-source/sos-4.4260/sosppx4.zip 
Archive:  sosppx4.zip
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
  583545  Defl:N   273217  53%  12-03-02 21:34  a1598864  sosppx4.exe
--------  ------  ------- -----   ----   ----   ------    ----
  583545           273217  53%                            1 file
======================================================================

A couple of comments:

1. There's something different about the memory allocation under DOSEMU.
   For the first pass of the Zortech C++ compiler to run without a stack
   fault when running under DOSEMU, I had to add a command line parameter
   to increase the default stack size (16384 bytes) substantially.  Using
   34148 bytes was enough, 34146 bytes wasn't.  Never had to do that under
   the same version of DOS (6.22) running natively.  This seems to me to be
   a surprisingly big difference and I wonder if it means something to you.
   If you want more information can investigate more easily when I'm back
   in England where the DOS box is.  At present I'm doing all this remotely
   from France (which is why I'm doing it at all:) and I can't talk to it.

2. I gave you the full output of the pkunzip command above to show that
   it says "80486 CPU detected" when in fact it's running on a 686 with
   the dosemu.conf '$_cpu' variable set to "80586".  I don't know whether
   pkunzip 2.04g is capable of recognizing a 586 so it might mean nothing.

If there's anything else you'd like me to try out on dosemu 1.3.0.0
while I have it running on Athlon/VIA/kernel 2.6.0 please let me know.

I've deleted bug number 832665.

73,
Ged.

Re: Dosemu 1.1.99.1 segfaults

[Stas Sergeev]

Hello.

Ged Haywood wrote:
>> -D9+M might be sufficient.
> Attached.
Rejected. False alarm.
What kernel are you using? Some kind of
2.6? You have to upgrade your dosemu in
that case.

> I haven't attached anything to the bug report.
The bug-reports without anything are
doomed to be ignored.

> It's very easy to reproduce the segfault, all you have to do is start
> the compiler and dosemu crashes.
Doesn't it crash for you on *any* DPMI
program now? It looks like an incompatibility
with the newer kernels and nothing more.
And this was already fixed but IIRC not in
1.1.99.1.

Re: Dosemu 1.1.99.1 segfaults

[Ged Haywood]

Hi Stas,

On Thu, 30 Oct 2003, Stas Sergeev wrote:

> Rejected. False alarm.
> What kernel are you using? Some kind of 2.6?

2.6.0-test5

> You have to upgrade your dosemu in that case.

Oh dear.  Upgrade to what?  Does it say that in the docs?
If so, where?  I haven't found anything about kernel versions
in the docs (and I used 'grep' to look:).

> Doesn't it crash for you on *any* DPMI program now?

I don't know, I haven't tried.  All I want to run is the compiler.

> It looks like an incompatibility with the newer kernels and nothing
> more.  And this was already fixed but IIRC not in 1.1.99.1.

If you will please tell me where or how to find the fix, I'll cease
troubling you...

73,
Ged.

Re: Dosemu 1.1.99.1 segfaults

[Bart Oldeman]

On Thu, 30 Oct 2003, Ged Haywood wrote:

> On Thu, 30 Oct 2003, Stas Sergeev wrote:
>
> > Rejected. False alarm.
> > What kernel are you using? Some kind of 2.6?
>
> 2.6.0-test5
>
> > You have to upgrade your dosemu in that case.
>
> Oh dear.  Upgrade to what?  Does it say that in the docs?
> If so, where?  I haven't found anything about kernel versions
> in the docs (and I used 'grep' to look:).

because we simply didn't know it at the time. And after that I didn't have
the time to release a new version.

> If you will please tell me where or how to find the fix, I'll cease
> troubling you...

the fix is in CVS and in the ML archives. Go to www.google.com, type
 kernel 2.6 dosemu
Click "I'm feeling lucky"

by the way 2.6.0-test5 is quite bad in conjunction with dosemu, you'll
get lots of "Debug: sleeping function called from invalid context at
 include2/asm/uaccess.h:473
 in_atomic():0, irqs_disabled():1" messages on the console.

I think this was fixed in test8 (by Andi Kleen).

Now at least I should aim to release dosemu 1.2.0 before Linux ships linux
kernel 2.6.0, so that at least one official DOSEMU will run DPMI programs
on one official Linux kernel.

Bart

Dosemu 1.1.99.1 segfaults

[Ged Haywood]

Hi all,

I have an old C/C++ compiler suite from Zortech, formerly Zorland,
later bought by Symantec, later I think dropped.  I use it under DOS
to compile just one ancient application which still keeps several
businesses running.

Under dosemu I have never managed to compile the entire application,
the closest I ever got was under dosemu 1.1.5, when 80 out of the 81
modules that make up the application compiled.  The remaining module
caused the compiler to cause dosemu to segfault, I think partly as it
is the largest of the source modules at about 197kB.  The next-largest
module of 185kB compiled OK.

The same compiler executables which ran reasonably well with 1.1.5 now
reliably cause dosemu 1.1.99.1 to segfault immediately on running.
They don't even get as far as reading a source file.

There are real mode and protected mode executable versions of this
compiler, called 'ztcpp1' and 'ztcpp1x' respectively.  Both are .exe
files.  The 'x' model executables of the compiler use a proprietary
dos extender which was at one time available with the Zortech suite,
and later available alone (and somewhat improved) as a product called
called X32.  The source is not freely available but I have a copy of
the X32 product.

The real mode version of the compiler runs but the protected mode
version causes the segfault.  The real mode compiler executable is not
capable of compiling my sources because of memory limitations.

I compiled dosemu with debugging enabled, ran 'dosemu -D+a -o debug'
and ran the two compilers - first ztcpp1.exe and then ztcpp1x.exe -
with no command line parameters, just to get the usual compiler usage
information message.  The resulting debug output is just under thirty-
one Megabytes, so I haven't attached it. :)  It comresses to just under
91kB with bzip2 so I can send it to anyone who's interested, together
with my compiletime-settings and dosemu.conf if required.  This is all
running on an Athlon1300, I can try it on other machines if that will
help, or I can let you have the compiler exectuables, I'm sure Zortech
won't mind.

The following lines might be of interest.

Here are the last lines of the 'debug' file:

----------------------------------------------------------------------
Do INT0x21: Using caller_function()
INT21 (0) at f800:4806: AX=6201, BX=1a3b, CX=0000, DX=1208, DS=073a, ES=0b31
int 0x21, ax=0x6201
DPMI: realmode hlt: 0xfc807
DPMI: initializing
DPMI: return to dosemu code for handling signals
----------------------------------------------------------------------

The following appears at the end of boot.log:

----------------------------------------------------------------------
ERROR: CS selector invalid: 0x0073, type=0 np=1
leavedos(36|0x24) called - shutting down
ERROR: leavedos() called from within a signal context!
----------------------------------------------------------------------

It's not a big deal for me that I can't compile this package under dosemu,
so I'm not worried about not getting a reply, but I thought you might want
to know that things in the dosemu/DPMI world still need some attention.

If you want any more information please let me know.

73,
Ged.