Closed Bug 1111545 Opened 10 years ago Closed 2 months ago

"TypeError: can't acess dead object" in client tab at startup.

Categories

(Other Applications Graveyard :: ChatZilla, defect)

x86_64
Linux
defect
Not set
trivial

Tracking

(seamonkey2.31 unaffected, seamonkey2.32 affected, seamonkey2.33 affected, seamonkey2.34 affected, seamonkey2.35 affected)

RESOLVED INCOMPLETE
Tracking Status
seamonkey2.31 --- unaffected
seamonkey2.32 --- affected
seamonkey2.33 --- affected
seamonkey2.34 --- affected
seamonkey2.35 --- affected

People

(Reporter: tonymec, Assigned: rginda)

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(2 files)

At every startup, I see the message "TypeError: can't access dead object" twice in the client tab. No other details. I searched the stdout/stderr log but couldn't find anything relevant. Apart from this message (and unlike what happened in bug 1108416) ChatZila starts up normally. I thought the duplication might be related to the fact that I autoconnect to both moznet and freenode (and no others) but OTOH a reconnect only rarely makes the message reappear (at startup, it's every time). I have seen this in various successive trunk nightlies and hourlies of SeaMonkey with various successive builds of ChatZilla before and after the fix for bug 1108416.
Can you try to find a regression window with mozregression on a profile with the latest CZ nightly build? ( http://mozilla.github.io/mozregression/ )
Flags: needinfo?(antoine.mechelynck)
(In reply to :Gijs Kruitbosch from comment #1) > Can you try to find a regression window with mozregression on a profile with > the latest CZ nightly build? ( http://mozilla.github.io/mozregression/ ) Do you mean keeping the latest cZ and trying to find the latest SeaMonkey without the bug, or vice-versa? Caveat: ATM my system won't boot without "Fan: Silent (minimum noise, but may reduce CPU performance" in the BIOS setup. This makes the system noticeably slower than it used to be. At least I could invoke "seamonkey -chat" to reduce startup time.
Flags: needinfo?(antoine.mechelynck) → needinfo?(gijskruitbosch+bugs)
"mozregression --help" tells me among others "--app {firefox,fennec,thunderbird,b2g}" Does it really not support SeaMonkey or is the help just out-of-date?
(In reply to Tony Mechelynck [:tonymec] from comment #3) > "mozregression --help" tells me among others "--app > {firefox,fennec,thunderbird,b2g}" > > Does it really not support SeaMonkey or is the help just out-of-date? I'll try bisecting manually, downloading what I can find on the FTP server.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Tony Mechelynck [:tonymec] from comment #4) > (In reply to Tony Mechelynck [:tonymec] from comment #3) > > "mozregression --help" tells me among others "--app > > {firefox,fennec,thunderbird,b2g}" > > > > Does it really not support SeaMonkey or is the help just out-of-date? > > I'll try bisecting manually, downloading what I can find on the FTP server. I expect that it really doesn't support SeaMonkey. You could file a bug about that; it shouldn't be hard assuming nightlies are somewhere similar. And yes, latest/earliest firefox/seamonkey with/without the bug - keep the cz version the same.
Sorry, the problematic change happened at a time when, for over a week, there were no trunk builds of SeaMonkey at all. Here's the relevant part of my bisection log: 20140921003005 is GOOD (2.32a1) http://hg.mozilla.org/mozilla-central/rev/5bd6e09f074e http://hg.mozilla.org/comm-central/rev/9717f3be5a20 20140930003005 is BAD (2.32a1) http://hg.mozilla.org/mozilla-central/rev/7c24470b6b3a http://hg.mozilla.org/comm-central/rev/d9ef713a866e Between these two there are no SeaMonkey trunk builds for any platform. I have to leave home now, until after midnight European time. Can you reproduce with SeaMonkey? With Firefox? If yes on the one and no on the other it would indicate a disparity, either a change in Fx that wasn't ported, or a change imperfectly made in Sm to get it to build again.
Flags: needinfo?(gijskruitbosch+bugs)
Phhhw! What a night! At 02:30 CET I was in front of the (locked) door to the building and realized I had left the key 5 storeys higher. Finally I could get in around 08:10 (half an hour ago or some such) when a neighbour got out to lead his son to school. Somehow I don't (yet) feel tired. I'll try to: (a) see if I can construct a Firefox profile for tests, with the latest cZ XPI and similar extensions.irc.* prefs as in my default Fx profile (which I keep for Fx31 ESR and don't want to mess with in Fx 35-37); (b) see if I can reproduce the bug with the latest Firefox; (c) search for a last-good/first-bad pair of Fx35a1 starting just around the timestamps in comment #6. (d) report here. Don't let this prevent you to try too. ;-) I'm setting tracking flags for what I tested, but considering the low severity of this bug I suppose that (unless the fix is trivial) everything other than "what will be trunk when the fix lands" might quite possibly be set to "wontfix".
First try: Cannot reproduce in 20141216030203 (Fx 37.0a1) https://hg.mozilla.org/mozilla-central/rev/b836016d82b5 BUT: my other profile includes 3 ChatZilla plugin scripts, viz. ctcp-notification, away-marker and joinint. The latter one is disabled at connect time by the command "/disable-plugin joinint" but remains installed. Let's install them one by one to see if one of them produces a change. If neither of the three makes the bug appear, I'll install my custom networks.txt.
Attached file away-marker/init.js
1. Add joinint => no change. 2. Add away-marker => the message appears in the client tab. The red horizontal separator does appear in the tabs. I'm attaching the culprit source so you can check if there's something obviously fishy about it. (I'm not competent.) Do you know if there exists a newer version to which I ought to have updated?
Attachment #8537794 - Attachment mime type: application/vnd.mozilla.xul+xml → text/javascript
(In reply to Tony Mechelynck [:tonymec] from comment #9) > Created attachment 8537794 [details] > away-marker/init.js > > 1. Add joinint => no change. > 2. Add away-marker => the message appears in the client tab. > > The red horizontal separator does appear in the tabs. > > I'm attaching the culprit source so you can check if there's something > obviously fishy about it. (I'm not competent.) Do you know if there exists a > newer version to which I ought to have updated? I don't know. From the source, it's also not clear to me what 'dead object' it's on about - presumably something that the script is touching, but I wouldn't know what that is. :-(
Flags: needinfo?(gijskruitbosch+bugs)
N.B. At startup, the horizontal red separator appears in the network tab but not in the channel or user tabs. I suppose they are not yet opened when my nick goes "away". After /back followed by /away, red separators appear in all tabs — and the message appears anew (one more time, not two) in the client tab.
(In reply to Tony Mechelynck [:tonymec] from comment #11) > N.B. At startup, the horizontal red separator appears in the network tab but > not in the channel or user tabs. I suppose they are not yet opened when my > nick goes "away". After /back followed by /away, red separators appear in > all tabs — and the message appears anew (one more time, not two) in the > client tab. Wait, do you set yourself as away on startup / immediately? I bet that if you don't do that, the message stops appearing - the error will relate to views that have gone away where the code tries to add lines of stuff, I imagine, and the code should be updated to deal with the fact that maybe the view has gone away (or we should make sure it can't get at views that have gone away - not sure which, it'd need more debugging on my side as it seems like it's going to be non-trivial to reproduce this...)
Isn't away state persisted from one session to the next (when using a single profile)? I start SeaMonkey with browser, mailnews and chat, and I autojoin on Chatzilla to a number of channels on both moznet and freenode. I may or may not make the rounds of those channels shortly after startup to see if thre's something interesting in one of them, but normally I will wait for the browser to have loaded my tabs (between 110 and 120 ATM) and for the mailer to have downloaded my incoming POP3 mail (including, among others, a lot of bugmail) and then I may start by checking the most itching bugs in the browser, or by reporting the spam that came into the mailer's Global Inbox; all that time I will not be lurking at all my cZ tabs at once, if someone says something without my main nick in it I probably won't notice it. When I go to bed, or to town, I usually leave the computer on, with the modem connected (at the rate I use the Internet, the monthly rate is predominant, I rarely use more than a fraction of my monthly KiB allowance), the mailar periodically checking mail and cZ watching the network. If someone says my nick, I'll see it in the network tab when I come back. I never use the "/clear-view" command. I sometimes use "/delete-view", for which I have the alias "/ll" (seen as a superlative of "/l" = "/leave") but that isn't very often either. From what I see, the message appeared at startup when (IIUC) cZ was trying to restore last session's away status while my autojoin tabs were still in the process of being loaded. However, after the tabs had stabilized, "/back" made the red bars disappear, then "/away" brought them back (in all tabs, whose number had not changed between both commands); then I looked at the client tab and a new instance of the error message had appeared. I did the Fx37 test autoconnecting only to moznet, and the message appeared once at startup. In my usual SeaMonkey profile, I connect to both moznet and freenode (though usually one of them, not always the same, reacts before the other) and the message appears twice, once for each of them (once there were several seconds between both MOTD displays and I happened to click the client tab between them). I must have got that script _somewhere_ on the Net, but that was years ago, and today I tried without success to find it back. Too bad the author did not deem it useful to put his name in a comment near the top of the script. When I was learning COBOL on mainframes some 40 years ago my mentor stressed the importance of verbose commenting in the code itself (any documentation that is not in the code may get lost, and therefore sooner or later will); I still think he was 100% right.
Do you hide/remove any of the tabs (such as the network tabs) during any of this?
Flags: needinfo?(antoine.mechelynck)
(In reply to :Gijs Kruitbosch from comment #14) > Do you hide/remove any of the tabs (such as the network tabs) during any of > this? No I don't.
Flags: needinfo?(antoine.mechelynck)
I can't reproduce this against current Firefox trunk. The message doesn't appear at all.
(In reply to :Gijs Kruitbosch from comment #16) > I can't reproduce this against current Firefox trunk. The message doesn't > appear at all. Not even with the script installed? I wonder what can be different between your installation and mine. Shall I attach my extensions.irc.* prefs (with passwords obfuscated of course)?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Tony Mechelynck [:tonymec] from comment #17) > (In reply to :Gijs Kruitbosch from comment #16) > > I can't reproduce this against current Firefox trunk. The message doesn't > > appear at all. > > Not even with the script installed? I wonder what can be different between > your installation and mine. Shall I attach my extensions.irc.* prefs (with > passwords obfuscated of course)? Yes, with the script installed. So yeah, I guess...
Flags: needinfo?(gijskruitbosch+bugs)
OK, here are the relevant lines from the prefs.js in my "cztest" profile. They are encoded in UTF-8 (including Greek letters mu and phi mixed with Latin alphabet). The ## at the start of some freenode channel names is not in error, and /echo statements have been used to temporarily comment away some commands which I may wish to reactivate someday. You may merge them with your prefs.js while Firefox-Nightly is not running on your corresponding profile; anywhere there is "aaaa" (without quotes) it means I have obfuscated something and you may want to modify the entry accordingly. In one case I have obfuscated a channel name and password because I don't think I'm at liberty to make them known; it's a channel which can only be accessed while identified to NickServ and when I do, ChanServ gives me chanop status. In addition I get halfop status (and immediately downgrade to voice) when joining #palemoon, I get voice status when joining #seamonkey, and I am owner of #Mozilla-eo. I don't know if these statuses are relevant to solving the present issue but, who knows? Oh, and the various alternate nicknames used are all GROUPed together with NickServ.
P.S. I have removed network preferences for all networks other than moznet and freenode; only moznet is autoconnected. I hope this removal is not a problem for debugging the issue.
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → INCOMPLETE
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: