GNOME Bugzilla – Bug 476498
loading manpage output a "The requested page was not found in the document "
Last modified: 2008-04-03 21:04:00 UTC
When loading a manpage for the first time in yelp, a popup is displayed : Page not found The requested page was not found in the document It is from "transform_final_func" in yelp-man.c However, manpage is displayed fine in yelp.
Why is this still unconfirmed? $ yelp man:info and $ yelp man:infocmp Still says "The requested page was not found in the document (path)/infocmp.1m.lzma" $ rpm -q yelp yelp-2.20.0-4mdv2008.1
Still valid :( how long will this last? yelp-2.21.1-2mdv2008.1 In fact, the page is properly displayed the very first time, but any subsequent call shows the same message.
Still valid with yelp-2.21.2-1mdv2008.1 4 months, now.
Thought I'd commented, sorry. Basically, I can't reproduce here from SVN head. The reason it's uncomfirmed is that I can't reproduce. I had suspected it was a problem with the LZMA patch used by Mandriva. Since I don't have LZMA support at the moment, I can't confirm this. One way to check this would be to uncompress the affected man page and recompress with gzip. Does it now work? Otherwise, I have no idea. Since I can't reproduce, I can't investigate.
yelp 2.21.2 in Mandriva doesn't have any lzma patch anymore, since you merged it upstream ;) I'm getting this error message only on some manpages, either lzma or bzipped2. It seems to appear only on the first time a manpage is accessed. Once you accessed it, if you quit and restart yelp, you won't get the error message anymore for this particular manpage.
(In reply to comment #5) > yelp 2.21.2 in Mandriva doesn't have any lzma patch anymore, since you merged > it upstream ;) Ye, figured. > > I'm getting this error message only on some manpages, either lzma or bzipped2. > It seems to appear only on the first time a manpage is accessed. Once you > accessed it, if you quit and restart yelp, you won't get the error message > anymore for this particular manpage. > That's just plain weird. We don't do any caching of man pages across instances. Could you attach one of the problem pages here (preferably bzip'ed)? Despite all my efforts, I can't reproduce anything like the error with SVN head :(
(In reply to comment #5) > yelp 2.21.2 in Mandriva doesn't have any lzma patch anymore, since you merged > it upstream ;) > > I'm getting this error message only on some manpages, either lzma or bzipped2. > It seems to appear only on the first time a manpage is accessed. Once you > accessed it, if you quit and restart yelp, you won't get the error message > anymore for this particular manpage. > Thanks for looking into that. I get exactly the opposite behavior. The first time I run 'yelp man:infocmp', the page is correctly displayed. If I quit yelp and re-issue the same command, I get the error dialog, but the page is shown. At that point, the dialog is shown every time on every page I try to see (e.g. yelp man:man). The compression type does not matter. Exactly the same happens with bzipped pages. I will attache nm.bz2 from /usr/share/man/man1 if that can help.
Created attachment 102947 [details] bzipped nm man(1) page
He-he. I think I found a possible explanation. Your computers are too fast :( Basically, the threading inside yelp causes a "page found" and "final" internal signal to be emitted. In fast (or multi-core) computers, this might result (for pages on length 1) in the "final" signal being emitted first and the resulting error to be pushed before we can handle the page request. That's just plain horrible and would explain why I can't reproduce easily. Anyway, I'm investigating now... I'll have a fix before 2.22 (and if anyone ever says I can't run code in my head faster than computers ...). *shakes fist at the sky* Why must you mock me like this?
Sounds good. My machine is indeed a 3GHz P4 with hyper threading enabled.
Created attachment 104124 [details] [review] A potential fix Since I can't reproduce the bug on my (slow) computer, I'm debugging blind. Can anyone try out this patch, see if it fixes the issue? From my crazy computer-in-my-head, it should work, but I really need someone to try before committing (as it's a fairly large patch). Patch is against recent SVN (should apply to 2.21.90). I think the patch also fixes a couple of other issues and may have some random debug spew. If this fixes the issue, I'll commit asap. Thanks
Created attachment 104126 [details] [review] Update The previous "fix" actually made things worse. This version should resolve that.
http://bugzilla.gnome.org/attachment.cgi?id=104126&action=view is looking good for me; I could reproduce the problem beforehand (Core 2 Duo laptop) and can't now.
Based on comment #13, I've committed this. If the bug reappears in yelp after 2.21.90, please reopen or file a new bug. Thanks. 2008-02-02 Don Scorgie <dscorgie@svn.gnome.org> * src/yelp-man.c: * src/yelp-transform.c: * src/yelp-toc.c: * src/yelp-info.c: * src/yelp-window.c: * src/yelp-docbook.c: * src/yelp-document.c: * src/yelp-document.h: Only propagate final signals once we have really finished processing documents Fixes bug #476498, hopefully + Fix looking for non-existant IDs once the document loading is complete + Remove debug spew when trying to add specifically defined x-yelp-index
*** Bug 520422 has been marked as a duplicate of this bug. ***
Better late than never, checked with yelp-2.22.0-2mdv2008.1 Thank you.