On Tuesday 22 October 2002 16:44, Dirk Mueller wrote:
> On Mon, 21 Okt 2002, Till Krech wrote:
> > Linux)" The message goes to stderr, so it's very difficult to see it (see
> > above) ;-)
>
> I see :)
Here is the message from the plugin (on stderr):
INTERNAL ERROR on Browser End: Some problem with the version 5

System error?:: Datei oder Verzeichnis nicht gefunden

... with default user agent:
Mozilla/5.0 (compatible; Konqueror/3; Linux)

>
> > > How does it load it ? with dlopen? valgrind should be able to survive
> > > that.
> >
> > yeah. it even runs konqueror itself with all these gimmicks in shared
> > libraries ;)
>
> Ok, I've asked Julian and he has no idea either. can you do a
> --trace-syscalls=yes to see which syscalls made it escape the simulated
> CPU? Its most likely a bug somewhere in valgrind.
I didn't think far enough. Valgrind was running but stderr of the child 
process was redirected to /dev/null. So I didn't view any output.
What I did now:
derived my own Process class from KProcess. Overwrote the function 
commSetupDoneC() which, as I found finally out, does this redirection to 
/dev/null and started the nspluginviewer with valgrind.

Now I'm finally staring at stack traces :)

The original commSetupDoneC() redirects all three std fds to /dev/null if 
Communication is NoCommunication.
Is this behaviour of KProcess really ok or should it at least be documented ?
Normally, I would expect, that these fds are inherited from the parent process 
and that they are only changed in case of Communication != NoCommunication. 

-- 
Till Krech from Berlin, Germany is happy with
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP * KDE: 3.0.8 (KDE 3.1 beta2)
Qt: 3.1.0-b2 * gcc version 3.2