mozilla writes to a different application's image memory

RESOLVED INVALID

Status

SeaMonkey
General
RESOLVED INVALID
17 years ago
13 years ago

People

(Reporter: Rainer Mager, Assigned: asa)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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

17 years ago
adding some folks that might know what's going on here. I don't.

Comment 2

17 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

17 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

17 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

Comment 5

17 years ago
i bet it could, please try to reproduce this w/ patched and nonpatched 
versions.
> 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.

Comment 7

17 years ago
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

17 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
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
reopening.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reporter hasn't responded, marking INVALID. Please reopen if you can answer
rkaa's question.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.