GNOME Bugzilla – Bug 358080
crash in Help: I was browsing man pages...
Last modified: 2011-01-05 14:18:18 UTC
Version: 2.16.0 What were you doing when the application crashed? I was browsing man pages in Yelp. I was reading a man page for lpr, and clicked on a link under the "see also" heading to get a man page for lpd. Something that may be significant is that the link for lpd did not have the number of the man page section in brackets after it, like the other links did. It had empty brackets, unlike the other links, e.g. the list looked like "lpq(1), ... lpd()". Distribution: NetBSD 3.0.1/macppc Gnome Release: 2.16.0 2006-09-26 (The NetBSD Foundation) BugBuddy Version: 2.16.0 Memory status: size: -11784 vsize: 0 resident: 22822912 share: 0 rss: 22822912 rss_rlim: 0 CPU usage: start_time: -12328 rtime: 0 utime: 1159411537 stime: 0 cutime:49271912 cstime: 0 timeout: 46005847 it_real_value: 0 frequency: 2914874 Backtrace was generated from '/usr/pkg/bin/yelp' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...0xee7d7d8c in ?? () from /usr/lib/libc.so.12
+ Trace 73442
Hi, Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so. In addition, does the lpd man page load normally (try 'man:lpd' without quotes in the searchbox on the toolbar)? Thanks
To answer your second question, yes, "man:lpd" causes Yelp to crash as well. (As an aside, I noticed there are some other minor issues with the way Yelp renders man pages, it misses text sometimes.) I've duplicated this problem on another machine, also running NetBSD 3.0.1, but the Intel port. This latter machine was the one I intended to recompile with debugging symbols on (since it's much faster), but the packaging database NetBSD uses seems to have gotten hosed by a hard disk data corruption problem (triggered by heat from lengthy compiles I think -- ha ha). Given my schedule, I won't likely be able to get anything usable with debug symbols until next week now, but I will get to this soon.
Created attachment 73988 [details] Screen shot of problem man page in Yelp versus in a terminal Screen shot, note also the "history" segment in Yelp versus in the terminal. I see truncated output in Yelp like that with some man pages, perhaps it's related somehow.
Okay, first off, the missing man section number in links is a red herring, I can duplicate this problem by clicking on any link within a rendered man page. (As an aside, in some cases man page references are rendered without functional links too.) Here's a full backtrace of the exact same steps I reported above: Script started on Tue Oct 17 22:04:56 2006 [disciple@arcusiii:disciple]$ gdb yelp GNU gdb 5.3nb1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386--netbsdelf"... (gdb) run Starting program: /usr/pkg/bin/yelp Type Manifest File: /usr/pkg/lib/firefox/components/xpti.dat nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded nsNativeComponentLoader: registering deferred (0) ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "Components.classes['@mozilla.org/xre/app-info;1'] has no properties" {file: "file:///usr/pkg/lib/firefox/components/nsExtensionManager.js" line: 2084}]' when calling method: [nsIFactory::createInstance]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "<unknown>" data: yes] ************************************************************ WARNING: Cannot create startup observer : service,@mozilla.org/extensions/manager;1, file nsAppStartupNotifier.cpp, line 112 ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "Components.classes['@mozilla.org/xre/app-info;1'] has no properties" {file: "file:///usr/pkg/lib/firefox/components/nsUpdateService.js" line: 833}]' when calling method: [nsIFactory::createInstance]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "<unknown>" data: yes] ************************************************************ WARNING: Cannot create startup observer : service,@mozilla.org/updates/update-service;1, file nsAppStartupNotifier.cpp, line 112 GFX: dpi=96 t2p=0.0666667 p2t=15 depth=24 ++WEBSHELL == 1 ++DOMWINDOW == 1 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsPermissionManager.cpp, line 645 pldhash: for the table at address 0x84d3720, the given entrySize of 44 probably favors chaining over double hashing. ++DOMWINDOW == 2 ++DOMWINDOW == 3 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsStringBundle.cpp, line 273 Note: styleverifytree is disabled Note: frameverifytree is disabled Note: verifyreflow is disabled --DOMWINDOW == 2 WARNING: unknown protocol in nsScriptSecurityManager::CheckLoadURI, file nsScriptSecurityManager.cpp, line 1394 ++DOMWINDOW == 3 WARNING: unknown protocol in nsScriptSecurityManager::CheckLoadURI, file nsScriptSecurityManager.cpp, line 1394 ++DOMWINDOW == 4 --DOMWINDOW == 3 WARNING: unknown protocol in nsScriptSecurityManager::CheckLoadURI, file nsScriptSecurityManager.cpp, line 1394 ++DOMWINDOW == 4 --DOMWINDOW == 3 WARNING: unknown protocol in nsScriptSecurityManager::CheckLoadURI, file nsScriptSecurityManager.cpp, line 1394 (yelp:3527): GLib-CRITICAL **: g_strchug: assertion `string != NULL' failed (yelp:3527): GLib-CRITICAL **: g_strchomp: assertion `string != NULL' failed (yelp:3527): GLib-CRITICAL **: g_strsplit: assertion `string != NULL' failed Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 2] 0x080641eb in convert_man_uri (uri=0x88b0ce0 "man:lpd()", trust_uri=0) at yelp-utils.c:825 825 yelp-utils.c: No such file or directory. in yelp-utils.c (gdb) thread apply all bt full
+ Trace 76904
Thread 7 (Thread 1 ())
Thread 4 (LWP 2)
Thread 3 (LWP 0)
Thread 2 (LWP 3)
I hope this is more helpful. Dave
Hi, Thanks for the (very detailed) stacktrace :) Do you have the "manpath" program installed on you're system? If not, is the MANPATH environment variable set? If neither are available, this may be the cause of you're crash. In which case, please try running: MANPATH=/usr/share/man:/usr/local/share/man yelp from the command line and try reproducing the bug. If this fixes the problem, you either need to install the manpath program (sorry, I don't know anything about it :( ) or export the MANPATH into you're environment permanently to view man pages. If this doesn't fix you're problem, please add another comment and I'll look again. Thanks.
You're correct, the crash is happening because MANPATH isn't defined. Regarding the manpath program, unlike Linux or FreeBSD, NetBSD and OpenBSD do not have it. In NetBSD or OpenBSD, MANPATH doesn't need to be defined unless a user wants a derivation from the standard search path, as man uses /etc/man.conf to find its system-defined search path. I would think though that since yelp is dependent upon one of those means of locating man pages that it should check to see if MANPATH is defined or manpath exists. It shouldn't segfault if it can't find a man page. It isn't portable to assume either of those means of location are always available; I don't think that assumption is valid in HP-UX or Solaris either. (Not according to online versions of their man pages I just checked. I'm not at work or I could confirm HP-UX.) What would be best is a warning that yelp can't find a man path to search. I will also report this to the people who do NetBSD's packaging infrastructure, there should also be a warning when the yelp package is installed that MANPATH needs to be defined for it to work with man pages. (I may also bring up the idea of supplying a manpath to help emulate the GNU version of man.)
I'm seeing some inconsistency here, between the initial TOC (code in yelp-toc-pager.c) and later URL lookup (yelp-utils.c): The former uses a fallback (/usr/share/man), the latter doesn't. I'd prefer them to behave similar, using common code if possible. A good default could be /usr/pkg/man:$prefix/man, where $prefix would be substituted at compile time. Even better to use G_SEARCHPATH_SEPARATOR_S consistently... Also, if MANPATH is set in the environment, it should be preferred over a systemwide "manpath" program.
Yes, I found it curious that I got a list of man pages to view and then yelp would crash when I tried to follow some of the links. Since I was talking about portability, concerning HP-UX, I missed a critical paragraph in the man(1) man page I consulted before. MANPATH should indeed normally be defined in HP-UX. (Though of course, that still isn't safe to assume.) One thing though that might trip up yelp is that HP-UX allows what are termed specifiers (%L, %l, %t, %c) to appear in the MANPATH, which "cause locale-specific directories to be searched" (e.g. an excerpt from the MANPATH I get on HP-UX 11.23: "/usr/share/man/%L:/usr/share/man:/usr/contrib/man/%L:/usr/contrib/man") I haven't noticed that particular way of handling locales on other Unices. (But I'm no man page functionality expert...)
Thanks. I've committed a fix to stop yelp falling over completely in the situation where manpath is unavailable and MANPATH isn't set. Now, it'll refuse to load man pages (available in 2.16.2). I am leaving this open though to address the other problems (Confirming the bug due to the inconsistency of man handing between toc and utils). 2006-10-05 Don Scorgie <dscorgie@cvs.gnome.org> * src/yelp-utils.c: Don't crash when manpath (prog) || MANPATH (env.) is available
I'm pretty certain that all of these problems are now fixed in git master.
Er, well, the links aren't there at the moment, but they will be if/when the patch series currently sitting at gnome-doc-devel gets merged!
One bug per report. I'm closing this because the original bug has been fixed.