Closed Bug 136040 Opened 24 years ago Closed 23 years ago

[OS/2] Taskbar disappears

Categories

(Core Graveyard :: RDF, defect)

Product:
Core Graveyard
Component:
RDF
Platform:
Other
OS/2
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: erdeve01, Assigned: mkaply)

References

Details

Attachments

(1 file)

Bad overlays.rdf
2.42 KB, application/octet-stream
Details
When i'm starting warpzilla, the taskbar dissapeares. (after a few days) Also Task is only showing Navigator ctrl-1 and composer ctrl-4 Other task i must start from desktop. I cant change with ctrl-3 or one other to that program. I must start it from desktop. This happens after a few days. When i install it again it works for a time (version 2002031114 and older)
I'm not going to be able to reproduce it with this info. Instead of reinstalling, could you try deleting chrome.rdf in bin/chrome directory and see if that fixes it?
It works to delete the chrome file, but it isnt a solution. I saw it also in earlier version
The problem is also in version 2002041811 1.0 RC 1 for OS/2
Attached file Bad overlays.rdf —
I've attached what the bad overlays.rdf looks last. I attached it as binary so it would upload properly.
In our investigation of this, what we have found is that an overlays.rdf (could be any of them) gets overwritten with NULL Characters. The file is EXACTLY the same size as the good version, it is just empty. Looking to chrome people for advice.
Assignee: attinasi → waterson
Component: Layout → RDF
QA Contact: petersen → tever
hyatt: any advice on this one? overlays.rdf getting overwritten with NULLs. Thanks
The 'few days' comment is puzzling. As long as the modification of 'installed-chrome.txt' is not newer than 'chrome.rdf' then the files overlayinfo/...../overlays.rdf are not regeneration, to my knowledge. A case where 'installed-chrome.txt' would be be updated is the case of doing an '.xpi' xpinstall to add/update packages.
Sorry for the few days comment. Now i know that i must replace the chrome.rdf i found out that its occurs when i rebot my pc. When i'm just restarting mozilla there is no problem. When i restart my computer it fails and i must delete the chrome.rdf
'mozilla' does not do anything different when started after a reboot, than it does when started at another time. (We do get launched automatically by the OS after a reboot on win32 if "quicklaunch" is enabled, but the code path w.r.t. chrome isn't any different in this case, to the best of my knowledge). So, if this only happens on a reboot of OS/2, I'd have to wonder if there is some other cause. mkaply: is this a widespread issue on OS/2, or just this particular case?
We have had quite a few reports. SUGGESTION to reporter. Once you have things working again, mark all overlays.rdf files under the chrome directory readonly. Then see if it happens again. If it happens again, it is probably operating system related and the OS ignored the readonly on the overlays.rdf.
Summary: Taskbar dissapeares → Taskbar disappears
*** Bug 141091 has been marked as a duplicate of this bug. ***
I've had several e-mails directly with Michael Kaply. Perhaps some of the things that I have found and told him may of interest and spark some new thoughts. First, it does happen after a reboot. The *.rdf file that is clobbered is either clobbered at shutdown or on reboot. I checked the file just before shutdown and it was OK and Mozilla was not running. After reboot and prior to starting Mozilla I checked again and the file was clobbered (all nulls). I saw this twice. At that point I was checking the file on boot up, just after bringin up Mozilla, just before exiting Mozilla, just after exiting Mozilla and finally just before shutdown. So, unless there is some funny delayed writing going on, this file is not being clobbered by Mozilla although Mozilla may be doing something that sets a chain of events in motion. I posted this problem to comp.os.os2.bugs to see if there might be some suggestions. There were two: 1. the culprit might be danis506.add which I was using instead of ibmis506.add. Unfortunately (see the next suggestion) the problem has not recurred and I still have not discovered a triggering scenario to test swapping out danis506.add. So I haven't tried that. 2. add another file to the directory in which the *.rdf file resides (these files are alone in a ../content directory). At that point I had already done that, thinking that copying the rdf file to a backup would allow me to restore the file when it got clobbered. And - the problem has not recurred since doing that even though I have deleted that file hoping to get the problem to recur. Now, recall that deleting a file doesn't really get rid of it. So I suppose its presence (although "deleted") may still be protecting me from having the problem recur. Really weird stuff going on here! Running OS/2 Warp 4 with Fix Pack 15. Jim
In my previous comments I left out a couple of details. First, when the rdf file gets corrupted, the file size and date are not changed. Second, there was one corruption after adding an additional file to the ..\content directory. That occurred when I first made a copy of the rdf file. Mozilla was running at the time I did it. I suspect that any protective affect that adding the file has probably doesn't work unless the file is there prior to bringing up Mozilla. Finally, when I was having the problem, it was occuring very frequently. I was trying to recreate the problem and once I discovered that rebooting was involved I was rebooting frequently. Jim Jim
The symptoms here are similar to those in bug #130569. I can assure readers that DANIS506.ADD is not involved, as the overlays.rdf corruption occurred on this machine and it is an all SCSI system. Moreover, it occurred on a drive here (E:) that had no other applications installed. Warpzilla was the only app to have any files on that drive. You might also care to read my comments in bug #130569 about skin changes and rebooting. It seems that something is left around by Warpzilla after it terminates, and can be picked up again when another session is started, but it is lost if the system is rebooted. Shared memory locked by a daemon process spring readily to mind. This would also be consonant with locked DLLs remaining after Warpzilla is shut down. Basically, it looks like the PM address space is not the only one running when you run Warpzilla. I detect the faint whiff of Java here, with a JVM running in a separate address space.
I don't buy into this theory... First, I use SCSI disks, so there is no 506 disk interface at all in my system. Second, I run Merlin, not Aurora. This system runs for about six years and the last fixpack was one or two years ago and never ever have files been NULLed. On the very same day I installed Warpzilla (and I never had earlier builds on the system) one file is being overwritten. I find it next to impossible that this might be OS related...
The theory about shared memory left over seems plausible. I experienced that I could not delete two directories when I re-installed Mozilla as described in bug #130569. They were the Chrome and the Profiles directories, and they were empty. There was no Mozilla process running, but I could not delete these directories. They did not contain any hidden or system files. After rebooting, they were still empty, but could now be deleted.
Oliver: That is VERY interesting. Can you recreate this at will? This sounds suspicious, like it may be the problem.
I just tried - no problems this time. I'll give it another shot after I have surfed some time. Last time I could not reproduce this three times in a row, but now it works as intended. I'll post a follow-up if it resurfaces. For now I think I'll give RC 2 a chance...
I have just had chrome/editor/content/overlays.rdf zeroed out using RC2 (build 2002051021) for OS/2, with both IBM fixes applied. This caused the mail and news icons to disappear. It has taken a few days, but the corruption eventually occurred. So this is still a problem with RC2.
I don't know what to do with this one. Are you still not sure it was Mozilla that zeroed it out?
It's a racing certainty that it's Mozilla. The only other option is the venerable screen saver, SSAVER 2.6, which I have been running since 1994 without any trouble. Since SSAVER opens nothing for output, that really just leaves Mozilla and the components of OS/2 or eCS.
I am experiencing the problem again with RC2. With RC1, the problem stopped when I added a file to the bin\chrome\overlayinfo\communicator\content\ directory. The problem did not recur after adding the file even though I later deleted the additional file in an attempt to recreate the problem. The only problem I have experienced is the nulling of bin\chrome\overlayinfo\communicator\content\overlays.rdf. None of the other overlays.rdf files has been corrupted. Right now I can recreate the problem every time simply by rebooting. This is what I do: 1. Erase bin\chrome\chrome.rdf 2. Start Mozilla 3. Shut Mozilla down 4. Examine bin\chrome\overlayinfo\communicator\content\overlays.rdf. Is has no nulls. It is 1862 bytes with 0 bytes of extended attributes. 5. Run chkdsk (without /f - Mozilla is installed on my boot drive). It shows a file allocation error in bin\chrome\overlayinfo\communicator\content\overlays.rdf. 6. Shut down OS/2 7. Reboot OS/2 8. Examine bin\chrome\overlayinfo\communicator\content\overlays.rdf. It is now all nulls. The file size is still 1862 wuth 0 bytes of extended attributes. 9. Shut down OS/2 10. Boot the utility disks and run chkdsk /f to correct the file allocation error. 11. Reboot OS/2. 12. Examine bin\chrome\overlayinfo\communicator\content\overlays.rdf. It is still all nulls but now the file size is 1024 with 208 bytes of extended attributes. I've run this scenario several times and I've done it with a few variations. If I bring up Red Hat Linux 7.2, mount my OS2 partition and do an ls -l on the corrupted file, it shows a length of 0. I did this once prior to running chkdsk /f. I can bring Mozillla up and down any number of times and everything is fine until I reboot. My guess is that the file is getting allocated incorrectly or the allocation is getting corrupted. On shutdown, hpfs silently corrects some of it but doesn't correct it right and doesn't correct it completely enough to satisfy chkdsk. Further, my guess is that the data itself isn't clobbered but rather the directory entry is clobbered and is not pointing to the right area of the disk. But, however this is happening, it has to be able to account for all the other experiences other people have had. With RC1 I couldn't recreate the problem quite so easily. Although the problem always occurred on a reboot, it did not occur on every reboot. It was begining to appear to me that I needed to do some stuff in Mail & News to get the problem to occur but I never quite nailed it down before it stopped. To make matters muddier, I have RC1 installed on another machine. I have never seen the problem on that machine. What's the difference? Well, the only things that I can think of that might possibly matter is that on that other machine Mozilla is not installed on the boot drive and I'm using a different kernel. On that other machine I have 128M of RAM and I downloaded one of the post-FP15 kernel updates so that I wouldn't need the loader patch to see all the RAM. This machine has 64M of RAM (which is another difference which might matter) so I it is at the FP15 level of the kernel. BTW, I have no screen saver and no Java installed in Mozilla because Mozilla needs Java 1.3 and I don't have eCS or MCP so I'm stuck at Java 1.1.8 (bummer). Also, marking the file readonly does not protect the file. Jim
Just to test whether or not it is HPFS corrupting the overlays.rdf files, I have installed a second copy of Mozilla on a JFS volume. This is now the active copy of Mozilla on the SMP system, while the uniprocessor system will continue to use the HPFS installation. I am running Java 1.1.8, for whatever that's worth.
This helps immensely. We all run JFS. Interesting. So the question is what would cause that to get corrupted on HPFS. I'm going to reformat a partition HPFS next week to try to recreate. Couple questions: 1. Do you do anything in Mozilla before you shut it down? 2. After you shutdown mozilla can you try renaming the overlayinfo directory and see if it says it is in use? Thanks I have a lot to go on now.
Answers to questions: 1. I normally clear the history and caches before shutting down Mozilla. 2. I can rename the overlayinfo subdirectory on both the HPFS and JFS partitions after running Mozilla.
After shutting down Mozilla run from the HPFS partition, I tried a DLETREE to remove the complete installation. The chrome subdirectory was busy, and OS/2 prevented the deletion.
After running Mozilla from a JFS partition, I *can* DELTREE the directory and remove it completely without rebooting! This is markedly different behaviour from the HPFS installation. I will now revert to using HPFS with the Aurora kernel, just to ensure that the issue is filesystem-specific, rather than related to the Merlin kernel.
When I ran Mozilla from an HPFS partition under the Aurora SMP kernel and then tried to DELTREE the directory, the system reported that E:\Mozilla\bin\chrome\overlayinfo\editor\content was still busy, and prevented the deletion. This is similar to the results when running under the Merlin kernel, except that the locked directory is a few more levels down. [For those who don't already know, the Merlin kernel is too old to access JFS partitions.] Given that everything was freed and deletable using JFS, the problem does seem to be specific to installations on HPFS partitions, regardless of OS/2 kernel.
Very interesing. I have updated to RC2, and I have never seen overlay.rdf corruption on RC2. I did exactly the same things when installing RC2 as I did when installing RC1. I can also deltree the entire Mozilla tree. With RC1 I sometimes had problems, but I could reproduce the error every time I tried. For info: I run the Merlin kernel on HPFS on my boot drive (logical, D:).
strange, i tested mozilla rc2 (2002051021) a few days without deleting chrome.rdf and it works now without disappearing the taskbar. First is tryed update ecs with the convienience pak 2 and nothing changed. But now in the rc2 version it works. After a chkdsk it stil works. also after rebooting (mozilla is installed on hpfs) I dont know what changed, but it works for me. I dont know if its comes back. But for now the problem is solved.
I seem to have a set up which for some reason experiences this problem more frequently than anyone else. I fire up Mozilla RC2, shut it down and reboot and it happens. Lucky me! To answer the question posted about my experience by Mike: no I don't have to do anything while Mozilla is up before I shut it down. It opens in Navigator brings up the home page (which seems to be empty BTW - http://www.mozilla.org/start/1.0/ - take away the /1.0/ and I get a valid page), then I shut it down. I am able to rename ...\overlayinfo after shutting down Mozilla. Jim
-> mkaply ... and add OS/2 to the summary, to make it clear that this bug is specific to OS/2 (and if someone has a similar, but not quite the same, problem on another operating system, resist the temptation to try to amplify this bug to cover more than OS/2. File a separate bug :-).
Assignee: waterson → mkaply
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Taskbar disappears → [OS/2] Taskbar disappears
*** Bug 130569 has been marked as a duplicate of this bug. ***
One question I raised in bug #130569 was about the apparent persistence of "skin" changes when the overlays.rdf files were read-only, but the loss of those changes after a re-IPL of the system. Are we any closer to getting an explanation for this?
skin changes are actually managed in the profile, not in the overlays.rdf files.
I had guessed that skin prefernces would be based in personal profiles. My observation was a correlational one: the change in read-only status of overlays.rdf was associated with an inability to change the skin persistently. One possibility is that code that should be writing to the profile just might be clobbering an overlays.rdf file instead. If this proves to be the case, one possible cause of this bug becomes clear. That's why I don't think you should dismiss this observation.
I now found a way to reproduce this behaviour at will. It will alway happen if the hard disk runs out of space. When you download something with mozilla and the particular hard drive becomes full, Mozilla will go through the roof with CPU load (100%). When you kill Mozilla, overlays.rdf is filled with NULL. So far I had Mozilla on that drive running full, I will try to find out what happens if the download drive is different from Mozilla' own drive.
Okay, when the drive containing the cache directory (which happens to be on a different drive here) runs full, Mozilla will also go for 100% CPU load, but after being killed, overlays.rdf remains intact (btw., OT, why is the default for cache 50 megs?) So I guess the problem has something to do with the drive running full, for some reason I do not understand overlays.rdf is being rewritten when Mozilla closes, and if there are 0 bytes available - boom!
On the 2 logical drives where I experienced the problems, there were tens of megabytes of free space and it did not need Mozilla to crash of be killed. The files were simply overwritten with zeroes.
Are you sure you had tens of megabytes free? If perhaps there is a download running for a large file, then OS/2s DIR will not tell you the truth for quite some time. File size of download files is being reported as 0 bytes for a long time...
I'm absolutely certain about the free space. I don't download to the drives on which I install applications. I have a separate physical hard drive for downloads. [This machine has 5 hard drives, with logical drive letters going all the way to Z:.] I also disable the disk cache for Mozilla, so it doesn't chew up any megabytes either.
Well, I've found a second fix that works for me: switch to the W41026 kernel. I was experiencing the problem on every reboot until yesterday when I installed that kernel update over the base Warp 4 FP 15. It hasn't occurred since. The other fix was to add a file, any file, to the ...\content directory so that overlay.rdf wasn't alone in that directory. Perhaps this will turn out to only make the occurrance of the problem less frequent. It seems that, with this problem, YMMV really applies. How does this compare to others' experience? Jim
Mozilla final 1.0 just passed the test with the install drive running full - overlays.rdf was not overwritten. But Mozilla still does not realize when the drive runs out of space, it goes to a wild 100 % CPU load and does basically nothing. Obviously it tries madly to get its download data written.
You may, perhaps, have been helped by the kernel fixes to the delete code. There were two parts -- part one went in at the FP16 level, and part 2, which fixed what I broke in part 1, went in as of 2002.04.01. -Scott
Based on all the information we have to date, I am considering closing this as an OS/2 bug. Any issues with that?
The earlier bug #130569 was marked as a duplicate of this one. There are still some issues raised in this that have not been adequately addressed, at least for my satisfaction, either as Mozilla bugs or OS/2 bugs. The reason I write this is because there appears to be some unxplained "persistence" of Mozilla that causes settings changes to survive during an IPL but not across an IPL. The combination (and correlation!) of this with the file corruption would seem to implicate OS/2, but why does this not occur with any other OS/2 app? The most likely candidate for such corruption would be some long-running app that does substantial amounts of disk I/O. A DB2/2 server springs readily to mind. I have run DB2/2 for several years now and not seen anything like this. Since the corruption (and other unusual results) seem to be specific to Mozilla, I don't think we can simply lay the blame on OS/2. I guess it boils down to: what makes Mozilla come in for such special attention from OS/2?
I wish I knew. Nothing special is even done with overlays.rdf. It is open, read, and then closed.
I did verify that we do nothing special with overlays.rdf at all. We open it, read it and close it. I have no place to go with this bug.
Has anyone seen this recently?
No, it is disappeared with version 1.0
ok, wfm. if anyone ever sees this again, reopen
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
QA Contact: tever → nobody
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: