Closed Bug 30247 Opened 26 years ago Closed 24 years ago

SETUP caused an Error by an invalid page in module UCONV.DLL (former [M13] in NECKO.DLL) similar or identical(?)to BUG #25878

Categories

(Core :: Internationalization: Localization, defect, P2)

x86
Windows 95
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: joachimkoch, Assigned: ssu0262)

References

Details

(Whiteboard: [DOGFOOD-])

When using the Installer, it aborts after a couple of time with the following Errror-Message: "SETUP caused an Error by an invalid page in module NECKO.DLL at 0137:60546877 Register (i have it only partially quoted[I#m too lazie]): EAX=00000000 CS=0137 EIP=60546877 EFLG=00010202 EBX=00000001 ....... ECX=00bf9f80 ...... EDX=81565a94 ....... " The Installation aborts with 0 Bytes installed!!!!! The Installer is dogfood.
Target Milestone: M13
Depends on: 26493
Keywords: dogfood
joachimkoch, Can you provide the URL that you downloaded the installer from? Also what is the System info say when you right mouse click on the My Computer icon and select properties? (I'm wondering if this bug is related to bug #25878) How is this related to bug 26493? That bug is about browser itself not liking WinGate. This bug looks like it's dying outside of the browser. Are you using WinGate too? Where did this crash happened (which component was is attempting to install)?
Depends on: 25878
Severity: normal → blocker
Priority: P3 → P2
Why the CS=0137 ist the same but the EIP=60546877 differs from BUG#25878?? I don't know, if BUG#25878 would be nearly identical or mostly different from BUG#30247. Who knows???? Thanks
The Crash happened exactly at the same point as described in BUG#25878!!!! But the register dump is different.
marking dup of #25878. joachimkoch, please continue to add any new comments to the above bug. It's easier to keep track of one bug. *** This bug has been marked as a duplicate of 25878 ***
Status: UNCONFIRMED → RESOLVED
Closed: 26 years ago
Resolution: --- → DUPLICATE
.
Status: RESOLVED → VERIFIED
Target Milestone: M13 → M15
A crash in NECKO cannot possibly be a duplicate of a crash in MOZREG! Also joachim has not given any specifics about the kind of system he is using so we don't know if that is the same. A crash during the install phase in NECKO would be extremely odd since necko is not part of the install engine. Are you sure it crashed while installing, and not after when it tries to bring up the profile manager?
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Now more precise: Build: The official Version of M13; System WIN95-A German Edition; Dump: Setup caused an error by an invalid page in NECKO.DLL at 0137:60546877 Register EAX=00000000 CS=0137 EIP=60546877 EFLG=00010202 EBX=00000001 SS=013f ESP=00657784 EBP= 006577cc ECX=00bf9f80 DS=013f ESI=00bf9f80 FS =10b7 EDX=81565a94 ES=013f EDI=8007000e GS =0000 Bytes at CS:EIP: 8b 08 ff 51 18 8b f8 8b 46 28 50 8b 08 ff 51 10 Stack: 00000000 8007000e 00bf9f80 60546187 00bf9f80 00000001 8007000e 00bf9f80 00ba927f 60545fa9 00bf9f80 6054623e 00000001 80000000 00657850 60c2d32a Hardware: i80486--166MHz--16MB-RAM--1.5GB-HD. build with the .exe; Then came the Install-shield: 1.) Extracting CORE.XPI MAIL.XPI SETUP.EXE SETUP.DLL 2.) Welcome to Mozilla Setup 3.)Click Type ... 4.)Setup will add.... 5.)Setup has enough...... Current settings Then comes an empty frame in that window ==>First abnormal behavior 6.) In that step the silly message of an SmartUpDate 7.) Then Installation had crashed
Target Milestone: M15 → M13
Sorry Sirs: Two silly messages of SmartUpDate a.) preparing SmartUpdate b.) processing? SmatUpDate then crashes with a new created directory with 0 bytes installed!!!!
Could that be a problem of localisation(e.g. the WIN95-A GERMAN edition with ASCI-8 signs like צה��)????
dveditz: Yes, I am very sure, that the bug happened during Installation (see very clerly described above) AND NOT AFTER INSTALLATION. I got 0 Bytes installed, but new directorys created!!! Therefore, it could really be the same as the Bug of marciales, the BUG#25878, because as the spanish Language has special chars, as the german Language has [much more exotic] special chars. It could then be (might be) an ASCII-7/ASCII-8 data-corruption.
It could well be due to 8-bit chars, but the odd thing is that NECKO.DLL is not used during installation and yet your steps indicate that the crash was during that phase (you had not seen the splash screen which indicates Mozilla itself had launched, and the error said SETUP had the crash not MOZILLA). We are not likely to go back to M13; does this crash still happen with the latest "nb1b" build? You will find this at ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/ Even though it is not in the "release" directory the "nb1b" builds are on the stable "Netscape Beta" branch and are actually better than the M14 milestone build. The ones that do not say "nb1b" are the regular nightly m15 builds and potentially unstable. But that'd be good info, too.
Sirs: I've tried it with the regular M14 build (2000-02-28-21 dated) and everything happenened exactly as discribed by marciales in his BUG#25878!!! Here the installation happened not with setup.exe (as in the regular build im M13) but with mozilla.exe. The firing dragon appeared, the a few minutes later (ca5-7) it crashed: MOZILLA caused an error by an invalid page in MODULE UCONV.DLL at 137:607f4905 Register: EAX=00000000 CS=0137 EIP=607f4905 EFLGS=00010206 EBX=00000000 SS=013f ESP=0068f9f0 EBP= 068fa60 ECX=0068f9fc DS=013f ESI=01061014 FS= 2757 EDX=00000073 ES=013f EDI=0068fba8 GS= 0000 Bytes at CS:EIP: 8b 38 8d 45 f8 50 53 ff 15 cc 70 7f 60 50 ff 35 Stack: 0068fba8 01062f90 007b2720 60c6be08 00000025 0000003f 00000000 00000000 0068fa14 6f736572 65637275 65722f3a 68632f73 65737261 696c6174 702e7361 The values Register, Bytes at CS:EIP, and the Stack are completly different as above im M13; The crash happened no longer in NECKO.DLL but in UCONV.DLL. Question: What does the UCONV do? Is it the ASCII-7 to ASCII-8 Convertation Routine??? Thanks.
Summary: SETUP caused an Error by an invalid page in module NECKO.DLL similar to BUG #26493 → SETUP caused an Error by an invalid page in module UCONV.DLL (former [M13] in NECKO.DLL) similar or identical(?)to BUG #25878
Target Milestone: M13 → M14
Sirs: Is it correct to make those changes or should I open a *new bug*?? Thanks.
Component: Installer → Localization
UCONV.XPT: There is standind in the executable an ASCII-Comment ns|CurrentCaractersetListener. Is a function with a similar name [e.g. listener(){...}] the *location* of the *localization-BUG#30247*?????? Then we would have the needle in the haystack. The mozilla would then be able for Continental-Europe Thanks.
Are you running some firewall software like ZoneAlarm or WinGate? See bug 28403 and other related bugs.
No Firewall at all, no network-card: I want to use bugzilla as an "Off-Line-Browser" for testing XML Code and for making first steps in XUL. So I can make wild test with no riddle on the LAN and the WAN. I'm Web-Programmer (HTML, JavaScript, PHP and when mozilla is there XML and XUL). The Sites also must run on UNIX and LINUX Clients ==> no IE!! Normaly *it doesn't matter a browser* during installation, that it is going to "localhost" or "127.127.127.0"!!! I really have doubt that this would be the riddle! Does an English version of WIN-95 on an *standallone PC* let mozilla crash??? Faszinating!
Depends on: 25321
It seems to be like BUG#25321 but it is no MAC! It's a PC strange. Now I know that Mozilla makes problems to be used as Off-Line-Browser (instead of signals sent to "localhost" or IP=127.127.127.0 Never thought, that this would make a difference. It's nearly like a dup of BUG#25321!!
It seems to be like BUG#25321 but it is no MAC! It's a PC strange. Now I know that Mozilla makes problems to be used as Off-Line-Browser (instead of signals sent to "localhost" or IP=127.127.127.0 Never thought, that this would make a difference. It's nearly like a dup of BUG#25321!!
Putting on dogfood- radar. need more info. can fix for beta2 if needed. msanz to follow up.
QA Contact: gbush → msanz
Whiteboard: [DOGFOOD-]
Target Milestone: M14 → M17
On a Win95 German Retail (no networking) I get the following error after choosing install folder and clicking next: 1157: Could not load C:\WINDOWS\TEMP\core.ns\bin\xpistub.dll This happens on M15 & M14 builds.
Daniel, what you ran into looks like bug #27601.
confirmign bug to take out of unconfirmed list . sorry for the spamm
Status: UNCONFIRMED → NEW
Ever confirmed: true
danielmc: Did the firing dragon appear, or died the mozilla earlier? (that happened to me in M-13 [official Version, no nightly buid]; in M-14[official Version, no nightly build] however the firing dragon appeared! [that's only the effect of different way of installation]). Which Version you took? The official or nightly builds? Thanks
ssu: You have written in your comment somewhat with BUG#27601. Do you think the adding of msvcirt.dll could help?
OK I have added MSCVIRT.DLL & MSVCRT.DLL to \windows\system the install now works. When the install (of any type) is complete the mozilla splash screen appears briefly. It then dissapears (M15-milestone) or crashes with the UCONV.DLL error as described above (M14-milestone) All the files appear to have been installed correctly from the xpi's In addition extracting M14 from the zip version and running mozilla.exe causes the same behaviour. It seems that this is not a installer problem. I also tested on Italian Win95 retail and fround no such problems with M14 or M15.
joachimkoch, this bug is different because setup is already installing files in this bug. While bug #27601 indicates that the user can't get to the installing files phase. This bug is more of a mystery. We're still trying to track this down. We know that it's not setup.exe itself, but rather the libs it uses to install the files. As one user already indicated that it also happens when mozilla.exe is run.
Sorry, I was mistaken to say that it worked on Retail Italian W95. What I should say is that it works on Retail Italian Win95 *if* TCP/IP networking is installed. It fails if there is no TCP/IP networking in the exact same way as on DE if there is no networking present. I have also tried on EN Win95b with exactly the same results and on English NT4 SP5 if I remove TCP/IP protocol Mozilla.exe also fails. I tried (variously) adding an IPX protocol and NetBUI but it still fails. So launching Mozilla is what causes the crash, not the install process (although the install process launches Mozilla at the end of installation). This crash is dependant on not finding a TCP/IP stack. Does UCONV.DLL have a dependancy on a TCP/IP stack present?
Similar? On SETUP exit, 3 errors in a row: (under Windows 98 NL 4.10.1998) SETUP caused an Error by an invalid page in module RPCRT4.DLL at p015f:7010183c. Stackdump: 00000000 00000000 70100000 81765c7c 7fd684cc 7fd03f2c bff741fb 0099fd90 0099fbbc 0099ff78 7010641f 70144a78 ffffffff 0099ff88 bff7ddcd 70100000 == Microsoft Visual C++ Runtime Library Program C:\WINDOWS\TEMP\NS_TEMP\SETUP.EXE R6016 -not enough space for thread data == SETUP caused an Error by an invalid page in module KERNEL32.DLL at 015f:bff7b997. Stackdump: 7803705c 78001075 78037130 00beb780 0099ff98 7800151b 0000000d 7800551c 81765c38 7800b87e 000000ff 00000001 00000000 7800bb0b 000000ff 00000010
Don not look like the same error to me. The crashes described here did ot occur in setup.exe. They were due to not having a TCP/IP stack present.
Resetting missed milestones
Target Milestone: M17 → ---
Keywords: nsdogfood-
Keywords: nsdogfood
is this still the case? I can't reproduce this. please reopen if it's still happening.
Status: NEW → RESOLVED
Closed: 26 years ago24 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.