Open SuperIlu opened 1 year ago
The same behavior can be observed using the stand alone SQLite.EXE. Makefile/compiler switches can be found here Compiler is DJGPP 2.05 with GCC 7.2.0 Use the following batch file to reproduce:
del test.db
sqlite test.db "create table foo (a integer primary key, b text); insert into foo (a,b) values (23,'42'); select * from foo;"
I don't see any flaws with the latest release.
You may want to clarify the actual steps to reproduce your said issue.
Hi, thanks for checking. You are right, the error does not occur with the default config. It does, however, occur with my config.
I narrowed it down:
The error does not happen with lfn=off
or lfn=auto
, I could reproduce it with the following dosbox.config
[dos]
lfn = on
[autoexec]
# Lines in this section will be run at startup.
# You can put your MOUNT lines here.
mount c C:\Users\iluvatar\Desktop\SQLite-bug
c:
del test.db
sqlite test.db "create table foo (a integer primary key, b text); insert into foo (a,b) values (23,'42'); select * from foo;"
This would be something for @Wengier as he implemented the LFN support (assuming he is available)...
Does it work properly if you boot MS-DOS 7.1 inside DOSBox and run it from there?
FYI, lfn=auto
means to enable LFN if the DOS version is >= 7.0, otherwise it is disabled. This is because some DOS programs get confused if they find LFN support on older DOS versions.
So you may want to try setting ver=7.1
to see if it makes any difference.
I can confirm that lfn=auto
and ver=7.1
also breaks SQLite.
I can also confirm that lfn=true
does not affect my Linux build (see initial post for details).
Since you reported that it worked on version 0.83.24, any chance of doing a git bisect
to find the offending commit?
I'd love to help, but
git bisect
before...I'd love to help, but
- I was not able to compile the MinGW version on Windows with the existing documentation (maybe I missed something?)
- I never used
git bisect
before...
Git bisect may not be necessary. First determine exactly in which configuration it does not work.
I am not able to confirm this error with lfn=true
or false
in dosbox-x-mingw-win64-20221227040641.
Your proposed configuration is incorrect.
I narrowed it down: The error does not happen with lfn=off or lfn=auto, I could reproduce it with the following dosbox.config
[dos] lfn = on
Get help. Each option has a description.
lfn: Enable long filename support. If set to auto (default), LFN support is enabled if the reported DOS version is at least 7.0.
If set to autostart, the built-in VER command won't activate/deactivate LFN support according to the reported DOS version.
lfn
accepts only these values.
Possible values: true, false, 1, 0, auto, autostart.
This is the exact configuration. I may have made a typo, switching on
for true
. But nonetheless it does happen when LFN is enabled.
@SuperIlu
I confirm. I ran dosbox-x-mingw-win64-20221227040641 under win10 and sqlite with lfn=true
doesn't work properly with the command you provided. It works in wine under linux.
Git bisect can be done without compiling. All needed dosbox-x builds are available here.
You just have to narrow down your search. Not commit after commit, only halfway between working version and non-working version. With any luck, you'll only need to download dosbox-x ten times (maybe more or less) and run the same number of times. It is trivially simple, although you need to spend some time on it.
@grapeli I'm not able to find the builds (to old? expired? skipped?).
I'll install msys2 and try compiling myself again...
@SuperIlu I misled you a bit. I didn't realize these builds are unavailable for download after a certain amount of time (sucks).
In this case, if you want to play self-compilation, you have a lot more work to do. Remember that compilation is not always successful. This is a task for people who play with it every day. You can only waste your time.
You are talking to someone who spent more than 3 years implementing Javascript on MS-DOS. I know how to waste my time properly! :)
It seems the offending commit is https://github.com/joncampbell123/dosbox-x/commit/a8cdcecd200fa9769b3b80acaf3940840ffcbf00
I have attached the transcript of my git bisect
session for interested readers...
bisect.log
iluvatar@twilight UCRT64 /e/_DEVEL/tmp/bisect/dosbox-x
$ git bisect good
a8cdcecd200fa9769b3b80acaf3940840ffcbf00 is the first bad commit
commit a8cdcecd200fa9769b3b80acaf3940840ffcbf00
Merge: bf2d8bd95 86644ca78
Author: Jonathan Campbell <6245486+joncampbell123@users.noreply.github.com>
Date: Wed Apr 20 22:58:29 2022 -0700
Merge branch 'master' into master
.gitignore | 3 +
CHANGELOG | 12 +-
include/fpu.h | 91 +++--
src/cpu/core_dyn_x86/decoder.h | 4 +
src/cpu/core_dyn_x86/dyn_fpu.h | 4 -
src/cpu/core_dynrec/decoder.h | 4 +
src/cpu/core_dynrec/dyn_fpu.h | 4 -
src/cpu/core_full/optable.h | 8 +-
src/cpu/core_normal/prefix_0f.h | 7 +-
src/cpu/mmx.cpp | 3 +-
src/debug/debug.cpp | 8 +-
src/dos/dos.cpp | 12 +-
src/dos/dos_ioctl.cpp | 3 +
src/dos/dos_programs.cpp | 5 +
src/fpu/fpu.cpp | 22 +-
src/fpu/fpu_instructions.h | 7 +-
src/fpu/fpu_instructions_longdouble.h | 7 +-
src/fpu/fpu_instructions_x86.h | 201 ++++++-----
src/gui/sdlmain.cpp | 2 +-
src/hardware/memory.cpp | 12 +-
src/ints/bios.cpp | 5 +
src/ints/bios_disk.cpp | 15 +
src/ints/int10.cpp | 12 +-
src/ints/int10_char.cpp | 614 ++++++++++++----------------------
src/ints/int10_modes.cpp | 32 +-
src/ints/int_dosv.cpp | 178 ++--------
26 files changed, 558 insertions(+), 717 deletions(-)
Not what you want to get from a git bisect
.... a huge commit that is all over the place.
Commit a8cdcec is pull request #3399 consisting of many smaller changes.
I downloaded the MinGW 0.83.24 release, but it DIDN'T work. I'm pretty confused.
Are you sure that you tried the MinGW version?
And the latest Visual Studio version works regardless of lfn
option.
The screenshot you uploaded has a Debug
menu, which is NOT available in MinGW builds.
Ah damn, seems like I switched from VS to MinGW without realizing. That renders the bisect useless I guess. :(
But now I'm very confused now that I got "good" and "bad" builds on the way...
Yeah, very confusing. At least we know that a flaw exists. We can take some time to figure out what the cause is, since there are multiple workarounds.
No worries and thanks for caring.
My main problem right now is that I need SLIRP as well as LFN for DOjS development, but I have enough alternatives so I'm good...
I think the title of the bug report needs to be corrected. Indications that only the mingw version is affected when lfn=true.
The difference in dosbox-x logs between vs and mingw comes down to this.
Dosbox-x-git-cfb71b3 built with the clang 16.0.0 compiler with address sanitizer with lfn=true
terminates causing stack buffer overflow. This is not the case with lfn=false
. Tested under linux.
dosbox-x.lfn.true.log
Should lfn=true
actually even be a configurable option for anything below DOS 7.x? If SQLite actually does something with the reported MS-DOS version then anything under ver=7.0
could easily break things, since older version don't have LFN support whatsoever. In that case it wouldn't matter whether DosBox-X supports LFN itself, since the application running gets mixed messages and breaks down.
Now I read the following from @SuperIlu :
I can confirm that
lfn=auto
andver=7.1
also breaks SQLite.
making this one a little more complex to solve, but the above question is also a bit broader. Should LFN support be allowed for configuration for any reported DOS version below 7.x?
making this one a little more complex to solve, but the above question is also a bit broader. Should LFN support be allowed for configuration for any reported DOS version below 7.x?
Valid question. But note that on legacy systems DOS 7.0 does not automatically mean that there is LFN support either. e.g., IBM PC-DOS 7 does not have LFN...
AFAIK the only 'valid' method to check for LFN is to call INT 71A0h and check if you get an error or not (see http://www.ctyme.com/intr/rb-3194.htm and http://www.fysnet.net/longfile.htm). LFN support on several DOS flavors is not tied to the version (e.g. FreeDOS), but if an TSR is loaded or not...
The latter part might be worthy of becoming an issue in its own.
@rderooy : True that, but since dosbox-x.reference.full.conf
states that it reports the MS-DOS version, I didn't bother to include MS anymore in my writings. If the reported DOS version is broader than that (so it could also include IBM PC DOS), I guess that should be reflected in the config-file. Major feature difference btw between MS-DOS 7.0 and 7.1 is FAT32 support.
Even broader, the question is what the validity of the whole option is. With the exception of RxDOS and seemingly PDOS, there is no DOS version that has LFN support built-in and they will all depend on Windows 9x to actually enable LFN support. I kinda doubt whether Windows 9x will respond well if LFN support is delivered through the kernel and thus not via the MS delivered drivers.
You probably still want the ver=7.1
if that is required to install Windows 98. The whole lfn=...
however seems to be irrelevant. In the end, both 7.0 and 7.1 (if MS-DOS) should respond to INT 71A0h.
With lfn=auto
and ver=7.1
configured, does DOSBox then enable doslfn? If so, doesn't that potentially interfere with Windows versions running on top of DOSBox?
EDIT: If the above logic holds, then isn't that the reason why SQLite could break with lfn=auto
and ver=7.1
(or lfn=true
for that matter)?
The moment you boot
another OS in DOSBox-X, it no longer matters what the integrated emulated DOS supports or not, as it will have a clean slate.
If you're running the Win9x SETUP
program from the integrated emulated DOS that DOSBox-X provides, you can run it from the default 5.0 reported version. The reason the example config files in the Win9x installation guides use VER=7.0
or VER=7.1
is simply to:
VER=7.1
@rderooy Do you say there in so many words that LFN support gets disabled if anything other than then built-in OS is being run? Because that might be the ideal way forward, but also adding to it being weird that SQLite crashes in the first place. If however some remnants still function while running Windows 10, there are effectively 2 places that can deal with INT 71A0h. That could easily lead to undesired results.
I am somewhat missing the logic though. INT 71A0h and accompanying functionalities get delivered through DOS kernel and then a driver (e.g., DOSLFN or Windows LFN API) "activates" this functionality. Why would you then include LFN support in DOSBox-X beyond INT 71A0h in the first place, since for True DOS the whole LFN thing wasn't a problem to begin with. With all those applications that are dependent on LFN having their own LFN API included it seems to be stacking features that do the same thing.
Not that I would immediately take out LFN support (again, beyond INT 71A0h), but the driver should be unloaded completely when anything else than built-in OS is being run to ensure for a mostly similar environment to being run on classic hardware, since that never included LFN support in DOS.
@JayQ2K yes, the moment you use the boot
command to start a guest OS inside DOSBox-X, things like LFN, EMS, XMS, mouse driver, etc are all gone. It is up to the guest OS to provide any such functions should it need it. DOSBox-X will only emulate the hardware side of things and the BIOS interfaces.
That is why I had asked you to boot MS-DOS 7.0 or 7.1 inside DOSBox-X to see if it makes any difference.
I'll leave the booting to other people since I just tagged along later. However, reading the above storyline, someone installed Windows 10 (effectively leading to the same place as installing MS-DOS 7, correct?) and then SQLite. If that is the case, then why would SQLite crash in the first place.
EDIT: still confused though. It LFN support shuts down when not running the built-in OS, then why have a configuration switch for it? That way you could actually force it to remain available.
ver=7.0
or ver=7.1
would effectively be called: LFN kernel support
lfn=true
or lfn=auto
(with ver 7.x) tells whether the driver or API is going to be run
The latter should not be a configurable option. You are, based on configuration, running with or without LFN kernel support and as long as you don't include your own application with LFN support, the driver will be run to enable FreeDOS LFN support.
I don't understand why you mention Windows 10 in this context. Windows 10 cannot be run inside DOSBox-X as a guest OS. It can only be used as the host OS on the system, to then run DOSBox-X as an application.
Sorry, turning some things upside down. It's DOSBox on a Windows 10 installation. My bad.
@JayQ2K again, once you boot
a guest OS, settings like ver=
or lfn=
no longer matter. Those settings are only for the integrated emulated DOS that DOSBox-X provides itself.
OK...? But then the question comes back to why #3898 can be an issue in the first place.
And ver=
seems to be usefull for the whole install Windows 9x and have long file names appear.
@JayQ2K @rderooy
I think you guys are not understanding this issue properly.
Visual Studio (and possibly Linux) builds WORK with regardless of lfn=true
and/or Reported version
.
Unfortunately, MinGW version doesn't, which is the point of this issue.
I don't know about other builds such as MacOS.
As you see in the following screenshot, long file name works even reported version is 5.00
on Visual Studio build.
And as you may know, we aren't talking about a booted guest, but a mounted folder on a native DOSBox-X prompt.
@maron2000 I don't have any Windows host systems for testing, so my own tests are only on Linux host systems, where there is not the issue of VisualStudio vs MinGW builds.
In any case I never claimed that sqlite could not work with older DOS versions with lfn=true
. I just pointed out that some software may get confused if you use LFN with DOS versions prior to 7.0. This is also why Wengier made lfn=auto
behave the way it does.
Lastly, I very much feel like we are going around in circles on this, so I will bail out of the discussion.
@rderooy
I also can't test all platforms so we can help each other.
I also want to remind you that the original poster of this issue already tried ver=7.1
doesn't work as well.
And I am always thankful of your comments to help others.
Figured as much the latter should become a separate issue. My thing mainly is (stemming out of this issue though): why have full LFN support in DOSBox-X and not just limit it to DOS LFN kernel support? When any application requires functionality as such, it will just rely on DOS LFN kernel support and be on its way.
ver=7.0
would then imply Int 21/AH=71h support
ver=7.1
means Int 21/AH=71h and FAT32 support
Int 21/AH=71h support would remain enabled with boot
since any given Guest OS could depend on it (why else would you configure ver to a 7.x option).
No, this makes no sense. When you boot
a guest OS, LFN and FAT32 support cannot and should not remain.
Ok. I'm done with this issue now, but: Int 21/AH=71h should be built in the kernel. An LFN API makes use of it if it gets exposed. So of course Int 21/AH=71h should survive boot
. It's just the LFN API that must be shut down under boot
. If you shut down Int 21/AH=71h altogether (meaning the result for 71h would be 7100h, not supported) after boot
then no way any application that is dependent on that support will function.
@JayQ2K Although you wish to, DOSBox-X now doesn't tweak a booted guest OS to enhance its functions (not limited to lfn), and it is practically not possible to implement such feature. Just use an guest supporting LFN, or use native DOSBox-X if you need it. MinGW version will not be an option until it gets fixed.
PRs #4645 and/or #4647 seems to have fixed this issue.
Describe the bug
build-sdl2
on ArchLinux works as expectedSteps to reproduce the behaviour
Expected behavior
The test should run with no errors beside a unique constraint (logfiles below created with 0.83.24
What operating system(s) this bug have occurred on?
Windows 10 22H2
What version(s) of DOSBox-X have this bug?
all releases since 0.83.24
Used configuration
Output log
No response
Additional information
No response
Have you checked that no similar bug report(s) exist?
Code of Conduct & Contributing Guidelines