https://bugs.winehq.org/show_bug.cgi?id=54532
Bug ID: 54532 Summary: msidb.exe: page fault on read access to 00000007 when importing a .idt file Product: Wine Version: 8.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msi Assignee: wine-bugs@winehq.org Reporter: luc.bournaud@gmail.com Distribution: ---
Created attachment 74078 --> https://bugs.winehq.org/attachment.cgi?id=74078 Backtrace
I am trying to import a .idt table generated by Wine's msidb into a MSI. This operation systematically lead to an NULL pointer dereferencement error. I tried multiples names and MSI files, It occurs on a up-to-date Wine 8.1-staging and Wine 8.2 (non staging) from official ArchLinux repositories. Wine prefixes were cleaned before each try.
For reference this is my command line and short output:
$ '/usr/bin/msidb' '-f' 'packaging/arcollect.msi.p' '-d' '/tmp/meson-1.0.0-64.msi' '-i' 'Control1' 0134:fixme:file:NtLockFile I/O completion on lock not implemented yet wine: Unhandled page fault on read access to 00000007 at address 6E42D714 (thread 0134), starting debugger... 0150:fixme:imm:ImeSetActiveContext (00030048, 1): stub 0150:fixme:imm:ImmReleaseContext (0002005A, 00030048): stub 013c:fixme:imm:ImeSetActiveContext (00020034, 0): stub 013c:fixme:imm:ImmReleaseContext (00020078, 00020034): stub
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #1 from luc.bournaud@gmail.com --- Created attachment 74079 --> https://bugs.winehq.org/attachment.cgi?id=74079 Control1.idt
The .idt file I am trying to import. This file use ISO-8859-1 encoding (codepage 28591) so expect encoding issues with some editors.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #2 from Hans Leidekker hans@meelstraat.net --- (In reply to luc.bournaud from comment #1)
Created attachment 74079 [details] Control1.idt
The .idt file I am trying to import. This file use ISO-8859-1 encoding (codepage 28591) so expect encoding issues with some editors.
Thanks. Could try narrowing it down more by removing rows until you find one that introduces the crash? The 3 header lines should stay of course.
https://bugs.winehq.org/show_bug.cgi?id=54532
David Kahurani k.kahurani@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |k.kahurani@gmail.com
--- Comment #3 from David Kahurani k.kahurani@gmail.com --- The table doesn't import on Windows either but at least Windows catches and reports the error.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #4 from David Kahurani k.kahurani@gmail.com --- (In reply to David Kahurani from comment #3)
The table doesn't import on Windows either but at least Windows catches and reports the error.
I was mistaken, the error I was experiencing was not related. Yeah, this does import on Windows with no problems.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #5 from David Kahurani k.kahurani@gmail.com --- The problematic line is:
ArcoWebextDialog ctlgClUowK7Z2ZEeG_HiI_UN3CtJPE Hyperlink 135 70 220 50 65539 Afin d'enregister les uvres d'art, vous devez installer l'extension de navigateur. Pour ce faire visitez la <a href="https://github.com/DevilishSpirits/arcollect/releases/tag/v0.29">page des téléchargements</a> et sélectionner la bonne extension : - Pour Mozilla Firefox, cliquer sur le fichier en .xpi. - Les autres navigateurs ne sont pas supportés. Next
Well, it is not exactly a line because some of the text within itself contains newline elements. It looks to me like native MsiDB silently fails when fed with this line as part of a table. Native MsiDatabaseImportA fails when supplied with this "line" too implying that the "line" is invalid. Removing the newline characters fixes it.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #6 from Hans Leidekker hans@meelstraat.net --- (In reply to David Kahurani from comment #5)
The problematic line is:
ArcoWebextDialog ctlgClUowK7Z2ZEeG_HiI_UN3CtJPE Hyperlink 135 70 220 50 65539 Afin d'enregister les uvres d'art, vous devez installer l'extension de navigateur. Pour ce faire visitez la <a href="https://github.com/DevilishSpirits/arcollect/releases/tag/v0.29">page des téléchargements</a> et sélectionner la bonne extension :
- Pour Mozilla Firefox, cliquer sur le fichier en .xpi.
- Les autres navigateurs ne sont pas supportés. Next
Well, it is not exactly a line because some of the text within itself contains newline elements. It looks to me like native MsiDB silently fails when fed with this line as part of a table. Native MsiDatabaseImportA fails when supplied with this "line" too implying that the "line" is invalid. Removing the newline characters fixes it.
Does it skip this line on Windows or does it stop processing the file at this point?
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #7 from David Kahurani k.kahurani@gmail.com --- (In reply to Hans Leidekker from comment #6)
Does it skip this line on Windows or does it stop processing the file at this point?
I could be mistaken but it looks to me like it just creates an empty database.
I run
.\MsiDb.exe -f . -c -d db.msi ..\control.idt
on Windows(7) where control.idt is the file posted by the OP, without any edits.
I then run this code on the database:
#include <windows.h> #include <msiquery.h> #include <cstdio>
static UINT do_query(MSIHANDLE hdb, const char *query, MSIHANDLE *phrec) { MSIHANDLE hview = 0; UINT r, ret;
if (phrec) *phrec = 0;
/* open a select query */ r = MsiDatabaseOpenViewA(hdb, query, &hview); if (r != ERROR_SUCCESS) return r; r = MsiViewExecute(hview, 0); if (r != ERROR_SUCCESS) return r; ret = MsiViewFetch(hview, phrec); r = MsiViewClose(hview); if (r != ERROR_SUCCESS) return r; r = MsiCloseHandle(hview); if (r != ERROR_SUCCESS) return r; return ret; }
int main(int argc, char *argv[]) { MSIHANDLE hdb, hrec; DWORD sz; UINT r; const char *msifile = "db.msi"; char buffer[10000];
r = MsiOpenDatabaseA(msifile, MSIDBOPEN_CREATE, &hdb); if (r != ERROR_SUCCESS) printf("Couldn't open database \n");
r = do_query(hdb, "SELECT * FROM `control`", &hrec); if (r != ERROR_SUCCESS) printf("Couldn't query database \n");
buffer[0] = 0; sz = sizeof(buffer); r = MsiRecordGetStringA( hrec, 1, buffer, &sz); if (r != ERROR_SUCCESS) printf("failed to get string\n");
printf(" %s\n", buffer);
return 0; }
The database opens the file but the query does not run which I take to mean that the table doesn't exist which in turn means that the import didn't import anything.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #8 from David Kahurani k.kahurani@gmail.com --- (In reply to David Kahurani from comment #7)
The database opens the file but the query does not run which I take to mean that the table doesn't exist which in turn means that the import didn't import anything.
**The database opens fine ...
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #9 from Hans Leidekker hans@meelstraat.net --- (In reply to David Kahurani from comment #8)
(In reply to David Kahurani from comment #7)
The database opens the file but the query does not run which I take to mean that the table doesn't exist which in turn means that the import didn't import anything.
**The database opens fine ...
What happens if you pass MSIDBOPEN_READONLY instead of MSIDBOPEN_CREATE?
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #10 from David Kahurani k.kahurani@gmail.com --- (In reply to Hans Leidekker from comment #9)
(In reply to David Kahurani from comment #8)
(In reply to David Kahurani from comment #7)
The database opens the file but the query does not run which I take to mean that the table doesn't exist which in turn means that the import didn't import anything.
**The database opens fine ...
What happens if you pass MSIDBOPEN_READONLY instead of MSIDBOPEN_CREATE?
Same observation: Database opens, query doesn't run. However, now that you brought it up, the original database created by MsiDB(native) is 20k, when opened with MSIDBOPEN_CREATE, it gets replaced by a database of size 2.5K which indicates there might be some entries in the original database(?) I'm not very sure at this point but the query does indeed fail in both cases.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #11 from David Kahurani k.kahurani@gmail.com --- (In reply to David Kahurani from comment #10)
(In reply to Hans Leidekker from comment #9)
(In reply to David Kahurani from comment #8)
(In reply to David Kahurani from comment #7)
The database opens the file but the query does not run which I take to mean that the table doesn't exist which in turn means that the import didn't import anything.
**The database opens fine ...
What happens if you pass MSIDBOPEN_READONLY instead of MSIDBOPEN_CREATE?
Same observation: Database opens, query doesn't run. However, now that you brought it up, the original database created by MsiDB(native) is 20k, when opened with MSIDBOPEN_CREATE, it gets replaced by a database of size 2.5K which indicates there might be some entries in the original database(?) I'm not very sure at this point but the query does indeed fail in both cases.
It is likely that the size difference is caused by database metadata. Both sizes look too small to contain any data to me.
https://bugs.winehq.org/show_bug.cgi?id=54532
--- Comment #12 from Hans Leidekker hans@meelstraat.net --- (In reply to David Kahurani from comment #11)
What happens if you pass MSIDBOPEN_READONLY instead of MSIDBOPEN_CREATE?
Same observation: Database opens, query doesn't run. However, now that you brought it up, the original database created by MsiDB(native) is 20k, when opened with MSIDBOPEN_CREATE, it gets replaced by a database of size 2.5K which indicates there might be some entries in the original database(?) I'm not very sure at this point but the query does indeed fail in both cases.
It is likely that the size difference is caused by database metadata. Both sizes look too small to contain any data to me.
MSIDBOPEN_CREATE creates an empty database and will truncate if the database already exists.
https://bugs.winehq.org/show_bug.cgi?id=54532
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #13 from Fabian Maurer dark.shadow4@web.de --- Is this fixed by https://gitlab.winehq.org/wine/wine/-/commit/e1ddc58a259d80f16bf1e62f2342877... ?
https://bugs.winehq.org/show_bug.cgi?id=54532
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |e1ddc58a259d80f16bf1e62f234 | |28775e1b070a0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #14 from Hans Leidekker hans@meelstraat.net --- Fixed by e1ddc58a259d80f16bf1e62f23428775e1b070a0.
https://bugs.winehq.org/show_bug.cgi?id=54532
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.12.
https://bugs.winehq.org/show_bug.cgi?id=54532
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |8.0.x