Closed Bug 400291 Opened 17 years ago Closed 16 years ago

[10.5][PPC] Crash/hang when operating in Help menu

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Version:
2.0 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: marcia, Assigned: smichaud)

References

Details

(Keywords: crash, hang)

Attachments

(6 files)

Apple crash report
53.93 KB, text/html
Details
crash report
29.20 KB, text/plain
Details
Apple Crash Log
32.10 KB, text/plain
Details
details from mac os
110.25 KB, text/plain
Details
Sample of MineField after opening Help menu
83.71 KB, text/plain
Details
Another sample, now complete
33.39 KB, application/zip
Details
Attached file Apple crash report — 
Seen using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.8) Gecko/2007100816 Firefox/2.0.0.8.

STR:
1. I was checking for updates using the Help menu when I hit this crash. Gmail tab was open. I was not able to reproduce. Since it has something to do with cache I thought I should file it.
What's odd about this crash log is that it looks like the app was
quitting (nsAppStartup::DestroyExitEvent() is on the main thread's
stack).

Could you have pressed Command-Q by accident?

I am sure I did not press Command Q.  From what I remember I somehow ended up being in the "Search" field in the apple menu. The next operation I remember was moving down to check for updates, and then I crashed. At the time, Gmail was in a strange state, and I had about 4 tabs open.
> From what I remember I somehow ended up being in the "Search" field
> in the apple menu.

I assume you mean "in the Help menu".

> The next operation I remember was moving down to check for updates,
> and then I crashed.

I just tried this sequence, and got no crash.  But that doesn't mean a
whole lot.

Another question (possibly relevant):

Did you see this problem on clean install of OS X 10.5 (to an empty
partition, or to one that was erased while installing), or on a 10.5
install that upgraded from 10.4.X?

Yes, this is a clean install of 10.5 on my Mac Book Pro, where I have a partition for Tiger and a partition for Leoopard.
Assignee: nobody → smichaud
We don't currently have enough information to do anything about this
bug ... but I'll leave it open for the time being.

Marcia, please comment if you get more information, or if you notice
other bugs that seem related.

I am experiencing the problem, and tested it on both a upgrade and clean (format HDD + install) install of Mac OS X 10.5 Leopard.  I am running Firefox 2.0.0.8, with a number of extensions – but it crashes regardless of whether those extensions are enabled or disabled (or even present at all) and I also tried deleting my prefs.js file.

Of note:

1. The Help menu does NOT crash when operating it the first time.
2. It will definitely crash upon subsequently operating the Help menu (i.e. it will definitely crash if you launch the Help menu a second time)

Here is a slightly blurry, but nonetheless demonstrative video of the crash in action (taken with a mobile phone):
http://mintchocicecream.googlepages.com/20071101Firefox2.0.0.8crashonMacOSX1.3gp
Severity: normal → critical
I am also experiencing exactly the same as Si Chun Lam describes. I also have a clean install of 10.5 Leopard and also had this problem with beta releases of Leopard and earlier versions of Firefox too.
Kieran and Si Chun Lam: Do you get a similar crash report to the one I posted in the attachments? Would be helpful to see if the stack is roughly the same.
Attached file crash report — 

    
    

    
  
A couple of additional points, firstly the bug is not as reproducible for me, I have seen it many times but not as consistently as Si Chun Lam is experiencing. Secondly the report I just posted is from Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 i.e. PPC not x86.

    
    

    
  

      
      
      
      

        Attached file
          
        Apple Crash Log
        — 
      

    


  

    
    

    
  
Guess my bug # 422535 on the FF 3 branch is a duplicate of this? It recently worsened from "sometimes crashes" to "always beach-ball-of-death". My guess is that it's the new Search field Leopard inserts in any Help menu, in combination with FFs emulation of Cocoa menus. Perhaps the fact that it inserts a view?

    
  
Keywords: hang

    
    

    
  
crash id from the bug 422535: 83a67691-ef54-11dc-a7e4-001a4bd46e84

    
    

    
  
I am using the nightly builds of minefield, I had not noticed this bug until because I never opened the Help menu, but from daterelease firefox-3a.2008031104.dmg onwards Whenever I open the Help menu minefield freezes hard, I have to use force quit to quit it. I have some Mac-OSX 10.5.2(ppc) reports on what happened which I will attach.

    
    

    
  

      
      
      
      

        Attached file
          
        details from mac os 
        — 
      

    


  

    
    

    
  
My Hardware configuration is:
Model: PowerMac4,4, BootROM 4.4.2f1, 1 processor, PowerPC G4  (2.1), 700 MHz, 640 MB
Graphics: kHW_NVidiaGeForce2MXItem, GeForce2 MX, spdisplays_agp_device, 32 MB
Memory Module: DIMM0/J1600, 128 MB, SDRAM, PC133U-333
Memory Module: DIMM1/J1601, 512 MB, SDRAM, PC133U-333
Modem: MicroDash, Euro, V.92, 1.0F, APPLE VERSION 2.6.7
Network Service: Ethernet, en0
Parallel ATA Device: Maxtor 4D040H2, 38.16 GB
Parallel ATA Device: SONY    CD-RW  CRX170E
USB Device: macally, ALCOR, full_speed, 500 mA
USB Device: macally, ALCOR, full_speed, 200 mA
USB Device: PS/2+USB Mouse, low_speed, 500 mA


    
    

    
  


  
Added a sample of MineField after I tried to open the Help menu. At least part of it, as the complete sample is about 1MB and wasn't accepted. The hang seems to be in XRE_GetFileFromPath when the menu contents updates.

        Attachment #311235 -
        Attachment mime type: application/rtf → text/plain

    
    

    
  
(In reply to comment #18)
> I am using the nightly builds of minefield, I had not noticed this bug until
> because I never opened the Help menu, but from daterelease
> firefox-3a.2008031104.dmg onwards Whenever I open the Help menu minefield
> freezes hard, I have to use force quit to quit it. I have some Mac-OSX
> 10.5.2(ppc) reports on what happened which I will attach.

using FF30b4r2 on OSX 10.5.2, i've no problem.

but, with each/every recent (can't tell you yet with which release the problem began ...) Minefield, e.g. currently w/ 30b5pre 20080323 nightly, simply *selecting* the Help menu immediately pegs the CPU @ 100%.  no crash, no logged errors, simply a freeze, requiring a similar force-quit.

this is reproducible on multiple 10.5.2 machines, both in normal-mode, and in safe-mode.  the problem survives across reboots, as well as when logged in as a 'vanilla' user.

after any freeze/force-quit, immediately trying FF30b4r2 works fine -- no further reboot etc req'd.

    
    

    
  
> after any freeze/force-quit, immediately trying FF30b4r2 works fine
> -- no further reboot etc req'd.

This tells me that what's causing/triggering these crashes is
something else that people are doing ... perhaps a long time before
trying to open the Help menu.

Please keep this in mind.

Until we know what this is, it will be impossible to resolve this bug.

(By the way, I've already considered the possibility that bad
interactions with extensions, input managers and so forth may be at
fault.  But some of the crash logs posted here don't contain anything
"extra".  So I doubt that bad interactions with other software are at
fault.  I likewise doubt that profile corruption is at fault
... though it's always good practice to test with a clean profile.)


    
    

    
  
(In reply to comment #23)
> This tells me that what's causing/triggering these crashes is
> something else that people are doing ... perhaps a long time before
> trying to open the Help menu.

sorry, i don't understand your point here.  the only thing that i'm 'doing' is launchinf minefiled, rather than firefox.

note, the problem occurs even if Minefield is the 1st app opened after a cold boot, as vanilla user, in safe-mode, with a fresh profile.

what do you have in mind that *could* be done "a long time before"?

> fault.  I likewise doubt that profile corruption is at fault
> ... though it's always good practice to test with a clean profile.)

just to clarify, again, fully reprodcucible with a clean profile ...


    
    

    
  
Sorry Steven, but this is definitely *not* because of something that happened before. It is 100% reproducible, and directly caused by calling the Help menu. The sample I attached shows that it goes into an infinite loop, (and the full sample shows this even stronger). Basically, when the help menu is updated before it is shown, it makes a change that triggers the Help menu to be updated, leading to an infinite loop. My guess is that both Apple and FF are trying to observe auto updating of the menu, and each one triggers the other to update. Apple probably does it to add the search field. As this is so ubiquitous around Leopard users I am pretty sure it's not related to personal settings, but a fundamental problem in the way the Help menu is handled. To be clear: this is a serious bug, that must be fixed. IMHO, it ought to be blocking. 

    
    

    
  
Maybe I misunderstood what you said.

Please try this:

1) Run today's Minefield nightly (or alternatively run Firefox
   2.0.0.12).

2) Before doing anything else, open the Help menu (and let us know
   exactly how you do that -- using the menu? using a
   key-combination?).

Is this enough to cause a crash?


    
    

    
  
> this is a serious bug, that must be fixed

It won't get fixed until someone who can fix it (like me) finds out how to reproduce it.  I'm still not able to (and not for lack of trying).


    
    

    
  
> 1) Run today's Minefield nightly (or alternatively run Firefox
>    2.0.0.12).

> 2) Before doing anything else, open the Help menu (and let us know
>    exactly how you do that -- using the menu? using a
>    key-combination?).
> 
> Is this enough to cause a crash?

here's what i do:

(1) remove any/all prior minefield profile data
(2) dl this:
 @ ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/
 firefox-3.0b5pre.en-US.mac.dmg   17190 KB   3/23/08   11:46:00 AM
(3) mount image & drag app to App folder
(4) unmount image
(3) *shutdown* the mac
(4) start the mac, login as a 'vanilla' user
(5) launch the 'new' Minefield.app by double-click in Finder
(6) click/select the "Help" menu (far right item) in the Minefield top menu

@ this point, the CPU goes to 100%, @ the app is frozen/unreponsive -- no crash.

if rinse/repeat, but @ step (5), instead launch from terminal in safe-mode, the same thing happens.

that's all it takes. only way 'out' is a force/quit.


    
    

    
  
should mention, @

   (6) click/select the "Help" menu

the menu does NOT open/drop-down ...

    
    

    
  
> click/select the "Help" menu

By this do you just mean "click on the Help menu"?

> the menu does NOT open/drop-down ...

I sometimes see a small delay (about 1 second?).  But it always does (eventually) drop down, and I never crash.

Possibly relevant -- what kind of mouse (pointing device) do you have?


    
    

    
  
> By this do you just mean "click on the Help menu"?

yes.  just click on "Help", then CPU rises quickly to 100%, and stays there.

> > the menu does NOT open/drop-down ...
> 
> I sometimes see a small delay (about 1 second?).  But it always does
> (eventually) drop down, and I never crash.

hm.  never drops down here, and CPU will happily track @ 100% 'forever' ... well, at least for 3+ hours when I once accidentally let it go that long.

> Possibly relevant -- what kind of mouse (pointing device) do you have?

i can reproduce this with any of a stock Apple mouse, a PowerBook trackpad, &/or a Kensington ExpertMouse.


    
    

    
  
Thanks very much for your info, snowcrash, and for the work you've put
into this.

But some crucial piece of information is still missing ... and until I
find it I've got nothing to work with.

(And no, I currently have no idea what that missing information might
be.)

About all I can say right now is that this seems to only happen on OS
X 10.5.X (though on both PPC and Intel).


    
    

    
  
Steven, you *are* testing this on Mac OS X 10.5.x, right? If not, I am pretty sure from what I've seen here that you never will be able to reproduce it.

So either one of you FF developers *with* 10.5.x should try and fix this, or you have to deduce the bug from the crash reports and samples, or FF 3.x will *never* see the light of day on Mac OS X. There is no fourth option. 

As this is a hang, you probably get more info out of the sample. Bugzilla does not allow me to attach the full sample, so perhaps I can send a full sample directly to you if you need it?

    
    

    
  
(In reply to comment #32)
> But some crucial piece of information is still missing ... and until I
> find it I've got nothing to work with.

understood :-(

what's worrisome is, assuming that the minefield 30b5pre builds are (are they?) the precursors to the next FF30 beta, that this gremlin will be _introduced_ into the release branch ...

    
    

    
  
> Steven, you *are* testing this on Mac OS X 10.5.x, right?

Of course I am (on a new Mac Pro and a two-year old MacBook Pro).  Didn't I say that this seems to only happen on 10.5, and that I've been testing?

> that this gremlin will be _introduced_ into the release branch

From what others report, it's already there.

Are you not able to reproduce this on Firefox 2.0.0.12?


    
    

    
  
Another question, possibly relevant:

I've been using the en_us versions of everything.  Might it make a difference which language distro you're using?


    
    

    
  
Also which keyboard/language you've set the OS to.


    
    

    
  
I have en_us for everything. I *don't* have the problem with FF 2.0.0.11 and a clean start (removed FireFox from app support). I *do* have the problem with FF 3.0.x and whatever settings (with/without a clean start, with/without safe mode). 

    
    

    
  


  
Attached a complete compressed sample of minefield after trying to open the Help menu.

    
    

    
  
> Are you not able to reproduce this on Firefox 2.0.0.12?

hadn't tried ... haven't used FF2x-RELEASE for ages ... so,

  DL'd FF 2.0.0.12, repeated same-as-above   --> NO problems.
  FF30b4r2, repeated same-as-above, still    --> NO problems.
  Minefield NIGHTLY, repeated same-as-above, --> prob is 100% reproducible

    
    

    
  
(In reply to comment #38)
> I have en_us for everything.

same here.

> I *don't* have the problem with FF 2.0.0.11

as above, i'm OK with DD 2.0.0.12, too

> I *do* have the problem with FF
> 3.0.x and whatever settings (with/without a clean start, with/without safe
> mode). 

hm. that's different for me ... i'm OK with FF30x, but NOT with Minefield nightlies ...


    
    

    
  
> > I *do* have the problem with FF
> > 3.0.x and whatever settings (with/without a clean start, with/without safe
> > mode). 
> 
> hm. that's different for me ... i'm OK with FF30x, but NOT with Minefield nightlies ...

Sorry, I meant the MineField nightlies.

    
    

    
  
I've looked at your sample, Christiaan, and I don't see any smoking
guns in it.  Though all the reentrant calls to [SCTGRLIndex
indexCarbonMenu:withParentMenu:resultGRLs:isRootMenu:systemHelpMenu:]
do look suspicious (this may be some kind of infinite loop).  (In any
case this is system code, not Mozilla.org code.)

> I *don't* have the problem with FF 2.0.0.11

Your sample plus this makes me think your bug is different from most
of the others reported here.

Since you're easily able to reproduce it, though, here's something to
try (if you have the time and inclination):

By testing different Minefield nightlies, try to find a regression
range for your problem (try to find the nightly with which the problem
started).

You can download old Minefield nightlies from
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly (they're the
ones whose names end in "-trunk").

Please try this, too, snowcrash.


    
    

    
  
I also think there are 2 distinct problems: 1) a crasher that does not always occur, this happened to me with FF 2, FF 3 and the Minefield nightlies until about 2 weeks ago. 2) a hang, this occurs to me with the Minefield nightly for the last 2 weeks or so, not before. From the comments here I read that others like snowcrash experience exactly the same problems, or one of them. 

From the sample, the reentrant calls to XRE_GetFileFromPath seem much more serious, and that's not system code AFAIK. 

I may look at the previous nightlies if I find time. 

    
    

    
  
> the reentrant calls to XRE_GetFileFromPath seem much more serious

Those entries in your sample are all spurious -- they aren't calls to XRE_GetFileFromPath.

The reason is that all Mozilla.org distros have their debug symbols stripped.  Gcc (and whatever program you used to take your sample) tries to translate a given address into a human-readable symbol, but can't find one that corresponds to that address and takes one "nearby".

The only way around this is to do your own debug build and test with that.

Even in traces/samples made from builds without debug symbols, though, entries for system calls generally _are_ accurate.


    
    

    
  
Some thoughts about the cause for the hang. Apple now indexes all the menu items, and puts a Search field in the Help menu to search for menu items. So all the calls to indexCarbonMenu:... are just to index the titles of every menu item in the main menu, so it's expected there a quite a few. Now the problem occurs when it tries to index the Help menu. What I think is that Minefield automatically generates the Help menu when requested (is that correct?). Now when I call the Help menu, it starts indexing; to index the Help menu it calls the Help menu, which is generated, and this triggers indexing the menus (because that was not done yet), which calls for generating the Help menu, etc. Could that be the problem?

Also, perhaps you could rename the Help menu in the next nightly to see if the new Search field is indeed the problem (because that is inserted in the menu with the localized name Help). 

    
    

    
  
A _far_ more productive use of time would be to find a regression range.

So, Christiaan and showcrash -- if you're interested in getting this bug fixed, _please_ do the work (the testing of different nightlies) necessary to find a regression range for your hang.

(Both of you do seem to have the same problem.)


    
    

    
  
And to be useful, the range (of course) needs to be narrow -- e.g. a given date's nightly doesn't have the problem, but the next day's nightly does.

In my experience, given that narrow a regression range, it's often possible to guess which patch triggered a problem.  Then I could do a test build with that patch backed out, and ask you guys to test it.


    
    

    
  
The hang first occurred in the march 11 nightly.

    
    

    
  
> The hang first occurred in the march 11 nightly.

Thanks, Christiaan.

And snowcrash, please try to reproduce his results (i.e. test the
2008-03-10 and 2003-03-11 trunk nightlies, and see if it's also the
case that your hang doesn't happen with the 2008-03-10 nightly, but
does happen with the 2008-03-11 nightly).

I can't find any really obvious candidates in that range.  The one
that (to my mind) comes closest is the patch for bug 419036 ("Simplify
nsCacheEntryHashTable::VisitEntries and break 'friendship'") --
largely because the Firefox 2.0.0.X crash logs clearly have something
to do with "caching".

I'll make a test build with this patch backed out or disabled.  I hope
to do this tomorrow.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-11+01%3A08%3A00&maxdate=2008-03-11+01%3A08%3A00&cvsroot=%2Fcvsroot


    
    

    
  
Just to clarify my situation, I am using minefield nightly builds, any build beyond 2008031015 seems to work fine up until the moment I try to open the Help menu. Upon clicking the help menu the menu doesn't open up. minefield becomes non functional. Only a force-quit will kill minefield.

I am using a ppc-mac, I have not verified this problem on a macintel. I will do so on Tuesday in the office.
uname -a gives me:

Darwin Macintosh-2.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar  4 21:23:43 PST 2008; root:xnu-1228.4.31~1/RELEASE_PPC Power Macintosh

System Version:	Mac OS X 10.5.2 (9C7010)


    
    

    
  
O dear did I forget to mention that the freeze doesn't happen when the firefox-window is either minimized or closed ( as in only the menu bar is visible/active )

    
    

    
  
If I minimize the browse window, open the help menu, then recall the browse window with the help menu open mozilla doesn't freeze. If I try to open or close the menu with the browse window active minefield freezes.. 

    
    

    
  
Monchi, thanks for your additional information.

So you're telling me that you don't have the hang with the
2008-03-10-15-trunk Minefield nightly, but you do have it with the
2008-03-11-04-trunk nightly (and subsequent Minefield nightlies)?


    
    

    
  
> So you're telling me that you don't have the hang with the
> 2008-03-10-15-trunk Minefield nightly, but you do have it with the
> 2008-03-11-04-trunk nightly (and subsequent Minefield nightlies)?

reading above, i can now, also, verify that:

   2008-03-10-15-trunk Minefield nightly has NO PROBLEM

whereas

   2008-03-11-04-trunk Minefield nightly DOES exhibit the same problem/behavior as previously reported

looks like the 'culprit' lies in the changes bet 3/10 & 3/11 ...

fwiw, my

uname -a
Darwin sc.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar  4 21:23:43 PST 2008; root:xnu-1228.4.31~1/RELEASE_PPC Power Macintosh

as well.

    
    

    
  
2008-03-10-15-trunk Minefield nightly has no problem, and I have extensibly verified that by installing and reinstalling.

Minefield-2008-03-11-04-trunk nightly (and subsequent Minefield nightlies) jabe the bad behavior yes.

And I have checked each nighly seperate, first backtracking from current. installing and reinstalling each individual dmg.

    
    

    
  
I can confirm Monchi's observation that the hang does not occur with the browser window closed or minimized.

    
    

    
  
I found the cause of the hang, and you won't find it in the code. The Bookmarks menu has all kinds of generated submenus. One submenu, deep down, is Bookmarks > Bookmarks Toolbar > Smart Bookmarks > Recent Tags > (no title) > Bookmarks Menu. This links back to another submenu: the whole bookmarks menu! In other words: the generated bookmarks menu is circular, infinite Russian doll effect. The Bookmarks Toolbar submenu is added on (drums...) march 11. Now when you open the Help menu, Apple starts indexing the main menu bar and all its submenus. Because the Bookmarks menu is circular, this indexing process will never stop. Hence the hang. So I think you should remove any possibility for circular menus. I'll also file a bug report with Apple, because they should be prepared to deal with such a situation (e.g. don't index too deep). 

    
    

    
  
Small correction, the circular menu comes from Bookmarks Toolbar > Smart Bookmarks > Recent Tags > (no title) > Bookmarks Toolbar > Smart Bookmarks. and in fact there are a lot more similar self references, all through Smart Bookmarks and (no title). 

My advice: remove the automatic "(not title)" submenu from the recent tags. It's pretty useless anyway, and just a big mess, and I really fail to see what this submenu has to do with "recent tags". This will fix the hang.

And that would bring us back to the original problem: the intermittent crash when opening the Help menu, that appeared before march 11. Good luck.

    
    

    
  
the hang is not intermittent, but consistant, every tiome the Help menu is opened with the browser window on screen minefield freezes.


    
    

    
  
I'm not saying that. I say that the *crash* that appears in builds before march 11 was intermittent. And that one is still not solved AFAIK. It should now be clear that the hang and the crash are two different problems, though they may be both related to the menu indexing on Leopard.

BTW, it's not whether the browser window is on screen, but whether the browser window is the front window. E.g. the Help menu will work when you move another window to the front, e.g. the Preferences window. That's expected from my explanation. 

    
    

    
  
(In reply to comment #58)

Christiaan, your explanation sounds plausible.  Here's one way to test
it (for you and for others):

Create a new profile to which you don't migrate any bookmarks (so that
it doesn't have any more than the default ones).  Then try to trigger
your hang on a recent Minefield nightly -- I'll bet it doesn't happen.

Everyone has different bookmarks, and some have a large number.  I
actually seldom use bookmarks, and hardly have more than the default
ones.  This could explain why I've never seen this hang.


    
    

    
  
(Following up comment #62)

> One submenu, deep down, is Bookmarks > Bookmarks Toolbar > Smart
> Bookmarks > Recent Tags > (no title) > Bookmarks Menu.

I just gave myself a clean profile, to which I didn't import anything,
and tested with yesterday's nightly (2008-03-23-04-trunk).  I don't
see what you saw, but instead see the following:

Bookmarks : Bookmarks Toolbar : Smart Bookmarks : Recent Tags : [Empty]

Still, though, I think you're on the right track (I think this somehow
has to do with bookmarks).


    
    

    
  
(Following up comment #63)

And I had no problems opening the Help menu.


    
    

    
  
I just gave myself a clean profile, without importing anything, and the same thing appears. I used yesterday's nightly (haven't tried today's yet). Also note the bookmark path that leads to the problem: Smart Bookmarks : Recent Tags : (no title) : Bookmarks Toolbar : Smart Bookmarks. Now, *none* of these items is added by me, it's all automatically added by Minefield. The bug is in the addition of the "(no title)" item, which simply should not be there at all. I don't know why you don't see this, but I see this with 100% reproducibility.

    
    

    
  
The puzzle is how you got your circular bookmarks.  I don't have any.


    
    

    
  
Can confirm hang with minefield 2008032304 and circular bookmarks with a new profile. (Old PowerBook with MacOS X 10.5)

BTW Could this be timing issue? Old computers vs new more powerful computers?

    
    

    
  
> BTW Could this be timing issue? Old computers vs new more powerful computers?

I don't know, but I doubt it. How could a timing issue add extra submenus? It is certainly partly an FF bug, because FF adds the (no title) item. I'd certainly look in the mozilla code to see where it may add menus with title "(no title)". 

Could it be that Recent Tags are cached somewhere? I did remove also ~/Library/Caches/FireFox, that did not help. 

    
    

    
  
On Linux I don't have circular bookmarks with a new profile. On Linux submenu
has "(Empty)" item that doesn't lead to anywhere. On Mac the corresponding
empty item leads back to the bookmark menu hierarchy as submenu.


    
    

    
  
> Could it be that Recent Tags are cached somewhere? I did remove also
> ~/Library/Caches/FireFox, that did not help.

It's conceivable that you'll find something interesting/relevant in
your org.mozilla.firefox preferences.  Try running the following
command from a Terminal prompt:

defaults read org.mozilla.firefox

>> BTW Could this be timing issue? Old computers vs new more powerful
>> computers?
>
> I don't know, but I doubt it. How could a timing issue add extra
> submenus?

I also doubt this is a timing issue.


    
    

    
  
Do any of you who are seeing this bug have input managers installed? They'd be in /Library/InputManagers or ~/Library/InputManagers.

    
    

    
  
>>> BTW Could this be timing issue? Old computers vs new more powerful
>>> computers?
>>
>> I don't know, but I doubt it. How could a timing issue add extra
>> submenus?
>
> I also doubt this is a timing issue.

I'd rather say it's rather a PPC issue (I have a PB G4). Perhaps a library having bugs in its PPC version. 

> It's conceivable that you'll find something interesting/relevant in
> your org.mozilla.firefox preferences.  Try running the following
> command from a Terminal prompt:
>
> defaults read org.mozilla.firefox

Nothing relevant there. Only keys added by Apple, HelixPreferenceFileID="com.RealNetworks.RealPlayer" and DefaultPluginSeenTypes=("application/x-java-applet;version=1.4.1"). (BTW, there are a lot of recent items from Apple that are supposed to be in the GlobalDomain prefs). 


    
    

    
  
> Do any of you who are seeing this bug have input managers installed? They'd be
> in /Library/InputManagers or ~/Library/InputManagers.

Yes, but that's not relevant. InputManagers in ~/Library are ignored on Leopard, and the only one in /Library does not load in FF (I know because I have the source code). Anyway, removing them does not change anything. 

    
    

    
  
Please ramina on subject, this is hte helpmenu that freezes up not the bookmark thread.

    
    

    
  
> Please ramina on subject, this is hte helpmenu that freezes up not the bookmark
> thread.

We *are* on subject, as we have established that the freeze of the Help menu is caused by the circular Smart Bookmarks menu. So the solution to the Smart Bookmarks will automatically solve the freeze with the Help menu.

BTW, I've got both a Smart Bookmarks and a Places item in the bookmarks bar, they look a bit similar. Maybe one of them isn't supposed to be there?

    
    

    
  
And the location for the problematic Recent Tags item is place:type=6&sort=14&maxResults=10. I don't know anything about the place: syntax, but is this correct?

    
    

    
  
I've changed the location to place:queryType=6&sort=14&maxResults=10 which looks more like the other items. After this change, the problem disappears! So the location of the Recent Tags in Smart Bookmarks is apparently wrong. Still, the weird (no title) item should never have been created, so the way place: URIs are handled is buggy, it should handle malformed queries better.

    
    

    
  
> place:type=6&sort=14&maxResults=10

I've got this for the location of Recent Tags, and I don't have any circular bookmarks.  So we still haven't gotten to the bottom of this (though I think we're close).


    
    

    
  
> pref("browser.places.updateRecentTagsUri", true);

I found this setting in the current trunk source.  It might be worth playing with it in about:config.


    
    

    
  
Tried those settings, and a few others in browser.places. Doesn't help. 

BTW, FYI, my Recent Tags menu looks like this (each one of the last items is again a submenu):

Recent Tags
  (no title)
    Tags
    Bookmarks Toolbar
    Bookmarks Menu
    Unfiled Bookmarks
    (no title)
    (no title)

It seems that the Tags submenu is in fact what *should* be the Recent Tags menu: it contains a submenu for each recently modified tag, containing the items with that tag. All the rest shouldn't be there. 

I looked a bit at the place: syntax, and indeed the current one should be correct. So the bug is somewhere in the code resolving the place: query.

From the syntax description, I'm not sure if it can return subfolders for queries. If it can, than it would be possible *by design* to add circular menus. That should be avoided at all cost, so if that could happen, the place: query syntax must be revised. I understand the syntax is still in development?


    
    

    
  
Frankly, I'm not sure I've ever had anything in my Recent Tags folder.

How do you trigger additions to it?


    
    

    
  
I also never had any, but I added some to test it out.

You can add tags if you click the blue star in the location bar (you may have to click twice, the first time to add a bookmark, the second to modify). My guess is that they then should turn up in the Recent Tags, but for me they turn up in Recent Tags : (no title) : Tags instead. 

    
    

    
  
Hmm in 2008031015 the bookmarks are circular as well.. just went 32 level without a single crash.. and still the helpm,enu doesn't freeze anything.. 

    
    

    
  
This is the bug that won't die!

I just what you (Christiaan) said (my added tag was "whatever"), and I don't see any (no title) item.  Instead what I now have is:

Recent Tags
  Whatever
   [the page that I tagged]


    
    

    
  
> Hmm in 2008031015 the bookmarks are circular as well.. just went 32 level
> without a single crash.. and still the helpm,enu doesn't freeze anything..

Clearly something happened on that date (on the trunk) to make things worse.

But I still think the underlying problem is the circular menus.  Once we figure out what's causing that, we'll (I hope) be pretty close to fixing this bug.


    
    

    
  
> circular menus

circular bookmarks


    
    

    
  
> I just what you (Christiaan) said (my added tag was "whatever"), and I don't
> see any (no title) item.  Instead what I now have is:

Sure, you probably won't see it, as it apparently happens only on PPC, for
whatever reason. The (no title) item is there for me, whether I have tagged
items or not. The bug is somewhere in the place: query parsing code, there's
where you or someone else has to look. 


    
    

    
  
maybe can test it by running macosx 10.5.2 in PEARPC ?

    
    

    
  
> Clearly something happened on that date (on the trunk) to make things worse.

See bug 408938.

    
    

    
  
> Hmm in 2008031015 the bookmarks are circular as well.. just went 32 level
> without a single crash.. and still the helpm,enu doesn't freeze anything.. 

No, this build does not have circular menus. The Smart Bookmarks in the
bookmarks bar is circular, but that's not relevant. It's only relevant for
menus in the main menu bar. And the Bookmarks in the main menu in 2008031015
does not have a Bookmarks Toolbar item. 

Anyway, it's clear the circular menus cause this. I just wrote an almost
trivial app that has a circular menu in the main menu bar, and it has exactly
the same problem. 


    
    

    
  
>> I just what you (Christiaan) said (my added tag was "whatever"),
>> and I don't see any (no title) item.  Instead what I now have is:
>
> Sure, you probably won't see it, as it apparently happens only on
> PPC, for whatever reason.

I think it's very unlikely that this is a PPC/Intel issue -- it's much
too high-level.  But unfortunately I can't do any tests of that myself.


    
    

    
  
on the MacIntel there are no problems with incursions on the bookmarks menu , and no freezes on clicking the help menu.

    
    

    
  
Apparently it does have to do with PPC/Intel. Note that different architectures basically run different compiled code. I can imagine some library that is used to have a problem in its PPC version, and some function returning an unexpected NULL or something, leading some other code to get confused. Low level bugs can easily lead to high level issues in this way.

    
    

    
  
found a workaround to this problem..
it's relatively simple: just manually remove the "Smart Bookmarks" from the "Bookmarks Toolbar", I am going to try to disable the creation of this in the about:config
browser.places.createdSmartBookmarks;false
Doesn't help, because next time minefield is tarted up it's set to true again and each time a new "Smart bookmarks" bookarksfolder is added.


    
    

    
  
Setting browser.places.createdSmartBookmarks to false does exactly the opposite of what you try to accomplish. It tells Minefield that the Smart Bookmarks was not created, so should be recreated (and it does so). Therefore you should set it to true instead. A better workaround is to change the location for the Recent Tags (or remove it completely). Or you should just be careful never to call the Help menu when a browser window is font (e.g. open a Preference window first). 


    
    

    
  
I see exactly what cristiaan describes on my Mac PPC, and moving the "recent tags" away from the bookmarks toolbar is working, i can again use the help menu.

I'm surprised this bug is not blocking beta 5, it freezes firefox every time both with new and old profile on Mac PPC.

If the content of the "recent tag" item has nothing to do with recent tags isn't it something that need to be corrected anyway ?

    
    

    
  
> If the content of the "recent tag" item has nothing to do with
> recent tags isn't it something that need to be corrected anyway ?

So you you never use tags?

You never choose Bookmarks : Organize Bookmarks, click on the name of
a bookmark, and type something into the "Tags" box?


    
    

    
  
I think he's referring to the situation on PPC macs, where the Recent Tags submenu is just a mess with no or little relation to tags. 

BTW, I filed 2 other bug reports related to this: bug 424884 and bug 424769. The latter is this mess with the Recent Tags, but focussed more specifically on the places issue (which I'm now convinced is a bug in resolving queries on PPC), and the former is about the fact that places can be circular (which is a more fundamental bug in the design of places queries). The latter has been marked as blocking for FF3. 

    
    

    
  
It'd still be interesting to know if the mess in the Recent Tags menu can appear "spontaneously", without the user ever explicitly having used tags.

Is that your experience, Christiaan?


    
    

    
  
I actually just went into the lab and played around with a build (turned out to be yesterday's nightly). I crashed several times. In one of the instances. I had focus on the Smart Bookmarks and then I crashed. In some cases during testing the menus become unresponsive (clicking on them did nothing, as if they were frozen). I will provide crash reports shortly.

    
    

    
  
The first one looks a lot like Christiaan's sample from comment #39.

The second ... who knows?

Marcia, does the mess in Recent Tags appear for you "spontaneously" -- say after having created a fresh profile, and without ever having added/created any tags?


    
    

    
  
> mess in Recent Tags

The circular bookmarks there.


    
    

    
  
Steven: I am fairly certain I saw the tags menu messed up with a new profile, but I can certainly go back and double check that fact.  I also experience the hang described, and have to force quit the app frequently on the PPC mac.

    
    

    
  
Confirming that the Smart Bookmarks | Recent Tags menu is horked using a new profile. Instead of what I see on Intel Mac and windows, I see exactly what Christiaan details in Bug 424769, which I have now confirmed. I grabbed a screenshot but the file was to big to attach to bzilla.

    
    

    
  
So (only on PPC Macs) the Recent Tags bookmarks are initialized to
garbage.

I can see how this might be a PPC/Intel issue:

Imagine an array of 32-bit values (unsigned ints), each of which only
"half" (16 bits) is initialized (because they haven't been initialized
correctly).  Further imagine that each of these 32-bit values gets
re-interpreted as four bytes.  On an Intel machine it will be the
"bottom" two bytes that are initialized (and the "top" two bytes that
are garbage).  But on a PPC machine it will be the other way around.


    
    

    
  
> So (only on PPC Macs) the Recent Tags bookmarks are initialized to
> garbage.

Another possibility is that it isn't garbage, but good data that's incorrectly interpreted (because of big-endian/little-endian issues).


    
    

    
  
I for one have never used tags in my bookmarks, at least not on my PPC systems.

I am thinking of verifying whether this problem is limeted PPC by either running PPC-Linux in a PEARPC-VM, using a PPC-Linux livecd or using my ageold purple iMac thats also running PPC-Linux.

    
    

    
  
PRovided I can find a built package for ppclinug

    
    

    
  
> It'd still be interesting to know if the mess in the Recent Tags menu can
> appear "spontaneously", without the user ever explicitly having used tags.
>
> Is that your experience, Christiaan?

Yes. I had never used tags before, the first time I used them was to test this issue. Also, it happens consistently with a newly generated Smart Bookmarks (after setting browser.places.createdSmartBookmarks to false and a relaunch) and with a clean profile.

    
    

    
  
> Another possibility is that it isn't garbage, but good data that's incorrectly
> interpreted (because of big-endian/little-endian issues).

This makes more sense to me than your previous one, as the content of the Recent Tags menu is always the same when it is regenerated. If it were garbage pointers, I'd expect random items.

    
    

    
  
don't mean to muddy the water, but I'm using a PPC mac and FF 3.0B4 on a fresh Leopard install.

I imported my profile and found a hang of 20-30 seconds when clicking on the "help" menu.

I created a new profile, and the menu responded as expected.

After importing my bookmarks the hang returned.

I deleted about 1/2 of the weight of my bookmards and the hang dropped to about 8 seconds.

I've not had crashes, just looooong hang ups.

Thanks for your efforts to resolve this.  I will try a minefield installation and see what happens.

    
    

    
  
This is a pretty severe issue for anyone using a PPC Mac and trying to get help. Requesting blocking.

Steven, should this be moved to Widget:Cocoa?
Flags: blocking-firefox3?
Summary: [10.5] Crash when operating in Help menu → [10.5][PPC] Crash/hang when operating in Help menu

    
    

    
  
> Steven, should this be moved to Widget:Cocoa?

No.  Though this is probably a PPC/Intel issue, it almost certainly isn't a Cocoa widgets bug.


    
    

    
  
> it almost certainly isn't a Cocoa widgets bug

That is if (as seems likely) the main issue turns out to be that the Recent Tags bookmarks are being initialized to garbage (or to data that gets interpreted incorrectly).


    
    

    
  
I wouldn't say that's likely. I'd say it's almost certain.

    
    

    
  
Now this bug has appeared in Firefox 3.0B5 as well.....
This is a showstopper.
What happens is that upon clicking the Help Menu, the search function in the helf menu starts indexing the bookmarks... Which is something the system will never end doing due to the cyclical nature of the bookmarks menu.

    
    

    
  
as mentioned before, this bug was NOT present in FF3b4, but WAS presence in Minefield >= 2008-03-11-04-trunk.

i.e., mostly out of the mainstream of FF users.

unfortunately, today's update to FF3b5 -- of course subsuming recent changes in -trunk -- has now exposed the problem to FF users as well -- i.e., the problem *EXISTS* in FF3b5.

i'm rather surprised, with the serious nature (crash) of this bug and the ever increasing documentation of the problem, that this was knowingly allowed into a *beta* release.

back to FF3b4 ...

    
    

    
  
I don't know about the rules for blocking. I know a related (and more general) bug currently is blocking for the FF 3 release. This definitely should also do that. And I also agree this should have blocked the beta. 

    
    

    
  
it'll be interesting to see how the no-longer-able-to-update-using-the-help-menu FF3b5 users will now update.

i'd wager that, even though using 'a beta' many rely on the Update function/capability to manage that process, rather than nav to the site, DL a fresh copy, etc.

argh.  i've just had two 'average users' report the problem.  it's begun.

now, sending out a company-wide memo to stay away from FF3b5, plus instructions for manual downgrading.  sigh ...



    
    

    
  
This can be caused if you manage to create bad loops in the bookmarks menu.  This has nothing at all to do with platform specific issues, its "if you have an infinite loop in your menu structure, the help menu will index that infinite loop"

We should fix the infinite loop issue in Places code, so you don't have infinitely deep menus.  We should also figure out how to kill overly-long indexing here, but there's a single known cause.

I strongly suspect that the users hitting this on upgrade have such a loop somewhere in their bookmarks toolbar, and now that we expose that in the menu, they're hitting that bug.

    
    

    
  
Mike, you're right and you're wrong. Yes, this is due to a loop in the menu structure, and yes, this should be fixed in the Places code (though so far nobody familiar with the Places code has taken this issue up). But there *is* an underlying platform dependent issue here, as detailed on this thread. Namely, on PPC Macs such a loop is created *automatically* by FF. So even when they did not have such a loop, FF will make sure they'll have one.

    
    

    
  
(In reply to comment #123)

And there also still is the original crasher, which has nothing to do with menu loops. 

    
    

    
  
this is a macosx-ppc 10.5.n only bug ( leopard ) 10.4.x doesn't have this bug./. it's clearly due to the new search function in leopard. So one might say it's a leopard bug.

    
    

    
  
(In reply to comment #126)
> this is a macosx-ppc 10.5.n only bug ( leopard ) 10.4.x doesn't have this
> bug./. it's clearly due to the new search function in leopard. 

This has been repeated already several times on this thread. 

> So one might say
> it's a leopard bug.
> 

It's at least partly a FF bug (bug 424769 and whatever causes the crash). And it doesn't help saying it's a Leopard bug, because FF will hang, and Apple won't fix this soon (you may be lucky if they do so in 10.6). 


    
    

    
  
Yes of course the looping has to be fixed.. But nonetheless apple should know about this bug, it happens with every program with a looping menuoption.

    
    

    
  
Of course, and I've already filed a bug report rdar://problem/5815407. Anyone else can do the same to increase its urgency, you can refer to mine. Their initial reply was not encouraging, she clearly didn't have a clue what I was talking about, even though I was very explicit. I hope they will reassign it to someone who understands the problem.

    
    

    
  
Good News: 

I reported above I didn't have Firefox crashes, only looong delays.  Bad news was as of FFb5 touching the help menu caused a crash.

Good News is that the Minefield buildS aren't exhibiting this behavior for me, as someone else mentioned above.

With this caveat:  as long as new profile.  Older profile that was working through FFb4 causes crash at launch

I've yet to test if I can somehow import just the bookmarks into the fresh file and see if operation is maintained, but the bookmark import only offers Safari imports so I will look to do this manually.


-—

Related small bad news:

However, the last day or two I've noted that selecting Check For Updates doesn't seem to work the first time, but does launch the check the second time 

Further checking this behavior showed that If I just activated the menu first, even without selecting anything, then released it, and tehn selected Check for Updates it would launch the Check For Updates process.



    
    

    
  
Good news, as of minefield 2008040604 the incursive bookmarks problem has been solved. So now openning the help menu in minefield doesn't crash anymore.


    
    

    
  
(In reply to comment #131)
> Good news, as of minefield 2008040604 the incursive bookmarks problem has been
> solved. So now openning the help menu in minefield doesn't crash anymore.

Not so good news. I'm running that same build right now on a 1,42 GHz PPC Mac. Opening time of the Help menu after Minefield start-up is 21 seconds at 100 % CPU. Later opening times of the same menu drop to an one second delay. 21 seconds to open a menu I do not call snappy. It is still a bug.

    
    

    
  
The latest nightly does not expand queries in the Recent Tags (expandQueries=0). That's why it's not circular anymore and the infinite hang is fixed. However the menu is still a mess, so it still contains a lot if items (like the full bookmarks menu and other stuff). That's why indexing (and hence first opening the Help menu) still takes a long time. 

BTW, I still occasionally see the crasher, but not as often as before March 11.

    
    

    
  
follow up:  imported the bookmards via the HTML export from my old FF file that works fine on Tiger/10.4. (because for some reason the import wizard only targets Safari)

While I had no delays with a fresh profile, even with the latest minefield (and a dual 1.25 GHZ G4 w/ 2 GB mem) my time until menu opening was 42 seconds, regardless of whether it was the first, or subsequent time opening it.  (yeah, i need to prune my bookmarks).

It did peg CPU Usage on one of the processors at 100%, as posted above.

    
    

    
  
Blocking for investigation, need to know how serious this is: how many crashes are we seeing with this? Possibly related to bug 427423? Possibly worked around by not indexing bookmark items when constructing the help menu?
Flags: blocking-firefox3? → blocking-firefox3+

    
    

    
  
> how many crashes are we seeing with this?

fwiw, we've ~ 100+ Macs here -- uniformly admin'd (read: likely, similarly configured).

as these are mostly technically-capable office users, but not developers, we'd "ok'd" testing/trials of FF3 betas.

~ 80 had DL'd/installed one of the FF3 betas. a total of 15 managed to DL/install FF3b5  -- all with this problem/crash in tow -- before we 'stopped the madness' and "advised" immediately dropping back to FF3b4.

over the weekend, we randomly sampled 10+ of the Macs that had NOT (yet) installed FF3b5.  *ALL* showed the same crash behavior.



    
    

    
  
Can someone provide breakpad report ids? (about:crashes) for those still seeing this crash?

snowcrash, are these all PPC macs?

    
    

    
  
Here's a fresh one: a38b76de-05b5-11dd-984c-0013211cbf8a

    
    

    
  
(In reply to comment #137)
> Can someone provide breakpad report ids? (about:crashes) for those still seeing
> this crash?

fwiw, in our case these arne't technically crashes, rather hangs -- requiring a force-quit to exit.

no breakpad/crash reports are created.

> snowcrash, are these all PPC macs?

good question. i would've bet good odds against -- but, yes -- all PPC.  the newest boxes ( ~ 30 ) are dual CPU G5s.  The rest range down to 1GHz G4s.

    
    

    
  
are people claiming crashes just not being patient enough? and are they testing the latest nightlies?  Sure, FFb5 did actually crash for me, but the latest Minefield nightlies do not...  The application, not the computer, locks up.

There is obviously changes at work here, the behavior keeps changing.  A few days ago I had 42 second delays on first and subsequent clicks of the 'Help" menu.  As of the latest build, the spinning beach ball doesn't show, and my delay is considerably reduced on the first click, and significantly reduced on subsequent clicks of the "help" menu.

Maybe they're not just being patient enough for it to return to working, because at first it was showing "unresponsive" in the Activity Monitor w/ a Spinning Beachball.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040804 Minefield/3.0pre

2) Above Christiaan gave us his bug report.  Unlike the open Bugzilla system, I don't believe we can look at or follow his individual reports.

I'm not savy enough to file a bug re: the menu; but if we want to turn up the volume I'd be happy to file one if someone can come up with some boilerplate text that we can submit.  I do have a student ADC membership, and have filed bugs when I was able to inteligently explain it.

Thanks all for continued efforts / attention to this, and all of FF!

Thanks

    
    

    
  
(In reply to comment #140)
> are people claiming crashes just not being patient enough? and are they testing
> the latest nightlies?

just to be clear abt our cases, testing the 20080407* minefied nightly, this hang will happily keep the CPU pegged @ 100% for hours, without crashing ...

    
    

    
  
Some points to make things clear.

The (real) crasher I reported in Comment # 138 was using a nightly from the previous day (2008040704), when I tried to open the Help menu to check for the new nightly. It was really a crasher, not a hang. I have edited my Recent Tags item to avoid the hang. So the crasher is not solved yet, but it does not occur as often as it did before march 11.

Also about the hang, to me it's clear what the situation is (on PPC). On PPC the default Recent Tags item gets you garbage. In the past, that garbage included a self reference and generated an infinite menu. As Apple indexes the main menu bar for the search field in the Help, this led to a never ending hang. In the recent nightlies, some changes were made to prevent infinite menus like this (bug 424884, the self reference is not expanded anymore). However Recent Tags still is a mess, and produces a very large menu, containing several copies of the Bookmarks Menu. So indexing is still very slow (read: hang), but it does stop eventually.

    
    

    
  
(In reply to comment #140)
> are people claiming crashes just not being patient enough? and are they testing
> the latest nightlies?  Sure, FFb5 did actually crash for me, but the latest
> Minefield nightlies do not...  The application, not the computer, locks up.
>
...

There is now a minimal delay again (2008041204) and things seem back to normal.  I certainly hope this isn't a random fix but either way, I'm happy to see the problem go away.  If it matters, I'd waited as long as 25 minutes while the browser worked at consuming available memory, real and virtual.


    
    

    
  
As of 2008041204 the incursive bookmarks seem to have been fully resolved. Someone with the authority please verify and close this bug.

Thanks for solving this one.



    
    

    
  
> There is now a minimal delay again (2008041204) and things seem back to normal.

using Minefield 2008041304, after ~5 seconds the Help menu drops down 'as normal', and Updates are once again functional.

yay, and thanks.

    
    

    
  
First, note that the 5 secs actually depends on the size of your bookmarks menu. For a large menu it can be significantly longer. 

Second, if this is closed, at least a new tracker should be opened for the original crasher (AOT the hang). I still see a crash once in a while, and I haven't seen any mention of this crasher being identified, let alone fixed.

    
    

    
  
Same size bookmark file tested on old 10.4.11 vs. relatively fresh 10.5.2:

(I say same size as Minefield was choking/quiting on old profile, created new profile and imported from html bookmarks, so not exactly the same file, but size wise at least equal)


10.4.11 = instant open of help menu and check for updates

10.5.2 = between 20-25 seconds first click on "Help" menu.  Subsequent clicks maybe 2 seconds?

Partitions on the same Machine:  MDD dual 1.25 Ghz, 2 GB Ram (no page outs), and SATA drives...so hardware not a bottleneck.

If it is believed that the bugs in FF/Minefield are as cleaned up as can be on this end, then please post a concise and constructive description of the alleged errors in the OS so that others w/ PPC machines and ADC access can report the bug.

BTW, is anyone else seeing this anomaly with any other applications in Leopard?

Thanks



    
    

    
  
(In reply to comment #147)
> Same size bookmark file tested on old 10.4.11 vs. relatively fresh 10.5.2:
> 
> (I say same size as Minefield was choking/quiting on old profile, created new
> profile and imported from html bookmarks, so not exactly the same file, but
> size wise at least equal)
> 
> 
> 10.4.11 = instant open of help menu and check for updates
> 
> 10.5.2 = between 20-25 seconds first click on "Help" menu.  Subsequent clicks
> maybe 2 seconds?
> 
> Partitions on the same Machine:  MDD dual 1.25 Ghz, 2 GB Ram (no page outs),
> and SATA drives...so hardware not a bottleneck.
> 
> If it is believed that the bugs in FF/Minefield are as cleaned up as can be on
> this end, then please post a concise and constructive description of the
> alleged errors in the OS so that others w/ PPC machines and ADC access can
> report the bug.
> 
> BTW, is anyone else seeing this anomaly with any other applications in Leopard?
> 
> Thanks
> 

Part of the problem is that 10.5.x has extremely reduced performance on many PowerPC machines.  It seems to be 2 - 4 times as slow as 10.4.10 for me.  Using a certain Java-based application is even worse.  Something that was instantaneous takes 5 minutes to happen now.

My thinking is that Firefox could probably be enhanced further but Apple has a huge performance problem on PowerPC machines that needs to be addressed.

    
    

    
  
bug 426499 covers the crash we're still seeing, which seems to be on both ppc and x86.  This was really the infinite loop bug leading to a differnet type of crash, but that one seems to have stopped showing up.

There's a bug to simply not index bookmarks at all, but that's been deemed too risky for Firefox 3.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME

    
    

    
  
So, I need to pose the Question again:

For others with larger bookmarks files will there be a caveat or part of the "read me" to say one should scale bookmarks files down to such and such a size?  Even when the same file size worked fluidly with Safari or FF under 10.4?

Or, if this is now absolutely an Apple issue could someone please post here or somewhere with a link here a way to verbalize the error we are to allege the OS is making for bug reporting through ADC?

Is there any other application that has delays like this on the Help Menu?  (Certainly if no other application is hanging like this it weakens the argument that it's the OS, no?)

------
to #148:
Please don't take this as disrespectful, but you may find Leopard performance on very few SPECIFIC tasks to be significantly less (and yes, I'm aware of examples where a specific task is deplorable, but to write off this error as saying Leopard PPC is generally slow seems a little off to me...I am thoroughly pleased...and I switch back and forth between them on the same machine and find the majority fluid and smooth.  Even benchmarking which was done on the initial (rushed out the door) 10.5 vs the 11th iteration of Tiger showed a mixed bag in testing that I saw.

So, if you feel that PPC users should be filing performance based complaints / bugs please suggest some broad tests we could describe to quantify and report the assertion.  I for one would gladly try testing and reporting my experience if need be.

Cheers



    
    

    
  
(In reply to comment #150)

> Or, if this is now absolutely an Apple issue could someone please post here or
> somewhere with a link here a way to verbalize the error we are to allege the OS
> is making for bug reporting through ADC?
> 

You can say that the automatic indexing of the main menu for the search field in the Help menu on Leopard can lead to a long or infinite hang when the menu is auto-generated by some app, which can be large or even infinite (which isn't a bug by itself). And that the individual applications should have a way to control over whether some menus are indexed. You can refer to my report from comment # 129. 

> Is there any other application that has delays like this on the Help Menu? 
> (Certainly if no other application is hanging like this it weakens the argument
> that it's the OS, no?)
> 

I don't know about other apps. But it is clear that it can happen far too easily, and by using completely legitimate features. That counts as a (serious) system bug in my books. Anything that is done automatically, and without allowing a single bit of outside control, must be totally and utterly fool proof, and this clearly isn't. IMHO, I am pretty baffled Apple didn't even foresee this problem, as it is a direct and obvious consequence of their implementation. Whenever you think "let's try and search everything" without knowing what "everything" really is, a big alarm bell should start ringing. 


    
    

    
  
Christiaan:

TY for the reply and explanation.  At first blush it made sense, but I keep coming back to the idea that I'm not seeing this in other applications.  I conducted one experiment that may shed some light on my concern:

my Safari and FF bookmarks "forked" some time ago.  The Safari set is considerably bigger to begin with, but just to really put things in perspective, I imported  and added the entire FF html bookmark file into my Safari bookmarks menu, making it at more than twice as large as the FF/minefield bookmark set that yeilds 20-25 seconds of help menu hang.

I went to the Help menu almost hoping to see a long pause, knowing I'd feel confident then filing the ADC bug report.  But, the Help menu opened as it always has.

I'm not sure if I've overlooked something here, but it would seem that either:
1)  the theory of the indexing is not quite right, 
2) Safari gets preferetial caching treatment, or, 
3) Safari  / Webkit has found a way to circumvent that indexing?  If the latter is the case, I would also suggest that perhaps jumping on the IRC channel or trying to have some exchange with them would be beneficial?

Thanks for considering this question/concern.

    
    

    
  
(In reply to comment #152)
> Christiaan:
> 
> TY for the reply and explanation.  At first blush it made sense, but I keep
> coming back to the idea that I'm not seeing this in other applications.  I
> conducted one experiment that may shed some light on my concern:
> 
> my Safari and FF bookmarks "forked" some time ago.  The Safari set is
> considerably bigger to begin with, but just to really put things in
> perspective, I imported  and added the entire FF html bookmark file into my
> Safari bookmarks menu, making it at more than twice as large as the
> FF/minefield bookmark set that yeilds 20-25 seconds of help menu hang.
> 
> I went to the Help menu almost hoping to see a long pause, knowing I'd feel
> confident then filing the ADC bug report.  But, the Help menu opened as it
> always has.
> 
> I'm not sure if I've overlooked something here, but it would seem that either:
> 1)  the theory of the indexing is not quite right, 
> 2) Safari gets preferetial caching treatment, or, 
> 3) Safari  / Webkit has found a way to circumvent that indexing?  If the latter

that should be easy to check: try to find a menu item in the bookmarks using the search field in the help menu. If it's found, that means it's indexed.

I'd rather say the slowdown is due to inefficiencies in the places code in FF. That's the big difference between FF and Safari. Note that the indexing triggers everything available in the main menu, and places searches several databases a few times. you could try and remove the special places items from the menu, my bet is that you won't see the slowdown.


    
    

    
  
Tried this, and it seems even without the place: bookmarks it's slow. So there is partly a problem with FFs bookmarks. 

A recent comment in bug 426499 made me suspicious. In short, FF generates the menus at the wrong time (as expected by Apple). this is done to avoid diverging the linux/mac code too much. I don't know how Apple gets the menus for indexing, but I could well imagine that this could lead to the slowdown. Perhaps during indexing FF regenerates the whole *menu* for every *item* that is indexed? If that is the case, it would make an O(n) process into an O(n^2) process. Any cs (or other beta) major should know that that's bad. 

BTW, this does not invalidate my remarks in comment # 151. Apple has a definite responsibility here. As a case in point, I had a similar problem once with AppKit searching a slow generated menu for shortcuts. In that case, Apple provides a way to prevent this. They should do the same for indexing.

    
    

    
  
...
> to #148:
> Please don't take this as disrespectful, but you may find Leopard performance
> on very few SPECIFIC tasks to be significantly less (and yes, I'm aware of
> examples where a specific task is deplorable, but to write off this error as
> saying Leopard PPC is generally slow seems a little off to me...I am thoroughly
> pleased...and I switch back and forth between them on the same machine and find
> the majority fluid and smooth.  Even benchmarking which was done on the initial
> (rushed out the door) 10.5 vs the 11th iteration of Tiger showed a mixed bag in
> testing that I saw.
> 
> So, if you feel that PPC users should be filing performance based complaints /
> bugs please suggest some broad tests we could describe to quantify and report
> the assertion.  I for one would gladly try testing and reporting my experience
> if need be.
> 
> Cheers
> 

I understand what you're saying.  The user interface is very responsive but
overall processing is very slow compared to 10.4.10.  Generally, I'm having
problems with most third party software but even iWork '08 is slower.  Every
time Apple makes changes to the virtual memory system, things get a bit odd
and/or slower.  Having 1.5 GB of RAM, I shouldn't be having a problem until I
have a lot of page outs.

I regularly move my Firefox bookmarks over to Safari's Bookmark menu and I'm
also seeing a slight delay with it as well as Firefox 2.0.0.13 but the delay
with Minefield is more noticeable.  I wasn't saying that code in Minefield
wasn't partly responsible, only that it's exacerbated by slow performance in
10.5.x.  TextMate and other software also shows a slight delay when accessing
the Help menu that wasn't there in 10.4.10.

I don't have any way other than batch tasks to quantify the slowdown but as far
as I'm concerned, Minefield is just one of many that exhibit it.  I can only
wonder if people at Apple actually read the crash reports, as I've sent them
plenty on this situation.

    
    

    
  
Should this bug really be marked:  RESOLVED WORKSFORME???

I am still getting an initial hang of roughly 25 seconds.

The hang isn't occuring in Safari or Webkit nightlies even with well  more than double the same size bookmark file...

If the decision to say it’s OK is based on starting w/ a fresh profile and no bookmarks, then we are setting ourselves up for a flood of bug reports later as people with real-world bookmark files move on w/ FF.  

If, it’s deemed OK as some people are arguing that PPC machines are generally slow on leopard are slow or crippled, then let’s get to some objective comparisons.  Annecdotal stories of woe are matchied w/ declarations that “it’s snappier”:

Geekbench (v2.0.15) 	Tiger = 		1092
Geekbench (v2.0.15)	Leopard = 		1027

				delta:  (1092 - 1027) / 1092 =	-5.9%
		
xBench (v1.3)		Tiger = 		69.16
xBench (v1.3)		Leopard = 		66.77

				delta:  (69.16 - 66.77) / 69.16 = -3.5%


Of course this audience doesn’t need an explanation that these scores are test dependent, and each test weighs different performance factors subjectively...both OS’s had strong and weak points.  Further, percentages of this magnitude aren widely acknowledged in hardware performance reviews to be undetectable to end users.

So, I’m not sure that this can be considered resolved / acceptable, or inconsequential. 
 
We may be at a point that satisfies people following the thread or beta testers, but when the FF version comes out undoubtedly we are going to be back to people starting over identifying this hang as a bug.

    
    

    
  
I'd say the initial *infinite* hang is solved. So I think it's appropriate to close this item. 

However, what about the initial crasher? Has that been solved, or is it one of the other 2 open crashers triggered by the Help menu? If it isn't, a new bug report should be opened. 

As for the long hang, I think that also should be a new bug report. Or is there already a tracker open for this problem?

    
    

    
  
I've got a tryserver build at bug 426499 comment #53 that eliminates
that bug's crashes, and also greatly reduces the delay opening the
Help menu (at least on Intel machines).  That's a different bug
(probably unrelated), but there's still a chance the tryserver build
will make a difference in the delays you two are seeing.

Please let me know your results with it.


    
    

    
  
(In reply to comment #157)
> As for the long hang, I think that also should be a new bug report. Or is there
> already a tracker open for this problem?
> 

To answer my own question: there is, Bug 414699. I'd say the discussion about slow opening should move there.


    
    

    
  
Christiaan:  Agreed...well done, regret I didn't see that with my earlier search when I got involved here...as that was my initial complaint prior to FF5.


Steven: your "tryserver" build reduced my slow menu hang from 25 to 9 seconds.


Again, many thanks for everyone's input and efforts.

    
    

    
  
thanks for all the hard work on this one.. problem solved (!)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: