Bug 2641 - Debug Session Druid truncates process/progress group names to 15 char
Summary: Debug Session Druid truncates process/progress group names to 15 char
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P3 normal
Target Milestone: ---
Assignee: Sami Wagiaalla
Depends on:
Blocks: 3401
  Show dependency treegraph
Reported: 2006-05-05 14:55 UTC by Len DiMaggio
Modified: 2006-11-21 21:17 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Len DiMaggio 2006-05-05 14:55:28 UTC
Debug Session Druid truncates process/progress group names to 15 char

I found this while writing automated GUI tests - I'm not sure of this has any
functional impact - the Druid truncates the names of processes to (15) characters.

So, gnome-screensaver becomes gnome-screensav

(The other Frysk GUIs display the same truncated names.)
Comment 1 Len DiMaggio 2006-05-10 00:25:40 UTC
The truncation is due to the kernel reporting only the first 15 chars of the
process name in /proc/PID/stat

Possible workaround - instead of the truncated process name, display information
from ps in this form:

	8456 /usr/lib/firefox- -UILocale en-U
Comment 2 Len DiMaggio 2006-05-11 01:09:37 UTC
It looks like the 15-char limit is imposed by the kernel - note the following
from the killall manpage:

   If a command name is longer than 15 characters, the full name may be 
unavailable (i.e.  it  is  swapped  out).  In  this case, killall will kill    
         everything that matches within the first  15  characters.

In order to debug a failure, a Frysk user will probably need both the process
name and target executable directory path - they may not match. So - we should
provide both via frysk. 
Comment 3 Len DiMaggio 2006-05-11 01:44:05 UTC
Another point of reference, the Gnome 'System Manager' refers to process names,
but I think displays the name of the running executables, as they are more than
15 char long.
Comment 4 Phil Muldoon 2006-05-11 02:30:14 UTC
After investigation, these are the findings.

The limit on the process name is in the /proc/$$/stat file, and following on,
the kernel. On consultation with other engineers, this is a historical feature
and unlikely to be changed. Also, it was pointed out  that it is limited more
than 15 characters due to encoding and stack limitations. James Antill noted the
reference for this was:


The full stucture is also encoded in the exe structure of proc, and this api is
provided through frysk-core with Proc.getExe(). However this is a privileged
operation, and is not accessible in all scenarios.

The last area to look at was getCmdLine which accesses the cmdline file in
/proc/$$/cmdline. This seems to be the best compromise, and we can extract the
executable file -> process map here. .getCmdLine[0] provides the full path.

Looking forward, multiple user assigned columns is the way forward, but for the
immediate future extracting the pathless exe name from cmdLine by doing
something like:

exeName = new File(proc.getCmdLine{}[0]).getName()

would work (with more null/error checking than in the above code ;)
Comment 5 Phil Muldoon 2006-07-19 16:10:40 UTC
Comment 6 Phil Muldoon 2006-07-19 16:11:35 UTC
2006-05-26  Sami Wagiaalla  <swagiaal@redhat.com>
	* datamodels/FlatProcObservableLinkedList.java: now using
	getNiceExecutablePath instead of getFullExecutablePath.
	* SessionProcTreeView.java: Added displaying of executable
	path of selected proc in the status bar.
	* MainWindowStatusBar.java: New file. Handle for the
	* GuiProc.java: Added getNiceExecutablePath which filters
	out all strange output of getExe() (part of fix for 2663).
2006-05-26  Sami Wagiaalla  <swagiaal@redhat.com>
	* sessions/DebugProcess.java: using getNiceExecutablePath
	instead of getFullExecutablePath.
	* glade/procpop.glade: Added a status bar.
	* druid/CreateFryskSessionDruid.java: using getNiceExecutablePath
	instead of getFullExecutablePath.