Closed
Bug 94042
Opened 23 years ago
Closed 23 years ago
mozilla writes to a different application's image memory
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: rainerm, Assigned: asa)
References
()
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010516 BuildID: 00000000000000 I use the xterm clone called aterm (aterm.sourceforge.net). This term allows for placing images in the xterm window including having the window "transparent" to the X root image (this is the option I use). After running mozilla and then closing it I noticed that the image my aterm displays now shows pieces of images that I browsed in mozilla. My guess is that mozilla is writing to memory it shouldn't be. It is possible the problem is in aterm but I've never had any problems with it after about 1 month's usage. Reproducible: Didn't try My Mozilla version is the most recent from CVS as of Aug-6-2001.
Assignee | ||
Comment 1•23 years ago
|
||
adding some folks that might know what's going on here. I don't.
Comment 2•23 years ago
|
||
I don't think mozilla has stepped into aterms memory, but I could be wrong. Can you try to reproduce it? If it is always reproducable then that theory is even less likely since it would be odd if mozilla would always happen to step into aterm's memory.
Comment 3•23 years ago
|
||
Also, could you attach the image you used in aterm when this happened and also with what options you started aterm.
Reporter | ||
Comment 4•23 years ago
|
||
I start Aterm with no options but I do have the following in my .Xdefaults file: Aterm*shading: 80 Aterm*tintingType: true Aterm*tinting: #ffffff Aterm*transparent: true Aterm*transpscrollbar: true I can not reliably reproduce the problem but I have seen it more than once. Next time it happens I will try to take a screen shot. Also I have seen the problem occur even before closing mozilla. That is, the act of closing mozilla doesn't make a differenc. I've changed the bug summary to reflect this. I should also mention that I am running a custom patched version of Aterm. I changed the way the shading (-sh) option works. My patch was placed on the aterm sourceforge site in the patches area. It is titled something like, 'change to -sh'. BUT, I don't think this would make any differenc in regards to this bug.
Summary: after closing mozilla a different application showed images that mozilla created → mozilla writes to a different application's image memory
i bet it could, please try to reproduce this w/ patched and nonpatched versions.
Comment 6•23 years ago
|
||
> Aterm*transparent: true
how is that implemented in X terms? do you ask the server for what's under you
and then render it?
It sounds like aterm has some sort of saveunder type thing that it does not
refresh correctly....
Mozilla writing into aterm's memory would more likely cause a SIGSEGV than this.
This has nothing to do with "an applications image memory" but is simply a case of a missing xrefresh, probably indicating a bug in the terminal emulator itself or your version of X. (Possibly on conjunction with your WM setup). To temporarily clear the mispainting just write "xrefresh" in the terminal window. I remember a similar problem with Xforms based apps refreshing extremely poorly under XFree86 3.3.* Wasn't mozilla causing it but a TV app i run. That matter was solved by upgrading to XFree86 4.0.3. Reporter: Which implementation/version of X are you running?
Comment 8•23 years ago
|
||
Marking these all WORKSFORME sorry about lack of response but were very overloaded here. Only reopen the bug if you can reproduce with the following steps: 1) Download the latest nightly (or 0.9.6 which should be out RSN) 2) Create a new profile 3) test the bug again If it still occurs go ahead and reopen the bug. Again sorry about no response were quite overloaded here and understaffed.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 10•23 years ago
|
||
Reporter hasn't responded, marking INVALID. Please reopen if you can answer rkaa's question.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → INVALID
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•