X11R5 und PEX

[Michael Zuelsdorff]

hi,

nach mehreren erfolglosen Anfragen in comp.windows.x versuch ichs hier
noch mal:

mein PEX funktioniert anscheinend nicht so, wie es soll. Wenn ich den
Beispiel-Client beach_ball starte, startet dieser 'phigsmon'. Obwohl
laut netstat neue TCP Kanaele (6100 und 6101) established werden, klappt
die Verbindung nicht-- beach_ball bricht mit diversen Meldungen ab.

der Wurm liegt in phg_cpxc_start_monitor (in cpx_clnt.c). Nachdem ich
dies testhalber ausdokumentiert und cph->configuration auf CP_LOCAL
gesetzt habe, laeuft beach_ball (wenn auch in Zeitlupe).

Also meine Fragen:
1. Wozu ueberhaupt phigsmon, wenns auch so geht ?
2. Hab ich ne ENVIRONMENT variable vergessen ?! bzw. was bringt die
Funktion MONITOR_USED dazu, CP_REMOTE oder CP_LOCAL zu setzen?!
3. wie kann ich ein Programm, das forked, (fork_monitor in cp_ccom.c)
debuggen ?

Schoenen Gruss
micha

[Hans-Ch. Eckert]

In <1992Jan01.1...@veeble.han.sub.org>, Michael Zuelsdorff writes:
] 3. wie kann ich ein Programm, das forked, (fork_monitor in cp_ccom.c)
] debuggen ?

Das wuesste ich auch gerne :-(

Und wann gibt es endlich einen gdb-frontend, der unter X11R5 laeuft ?
Seit dem Update auf R5 haben wir in der Uni keinen xxgdb mehr :-(

Gruss,
RIPLEY

--
Hans-Ch. Eckert, Regensburger Str.2, W1000 Berlin 30, Germany
rip...@nostromo.sub.org, ..!unlisys.in-berlin.de!nostromo!ripley
Also: rip...@opal.cs.tu-berlin.de, ...!fub!tubopal!ripley

[Matthias Urlichs]

In sub.os.unix, Artikel <1992Jan01.1...@veeble.han.sub.org>,
schreibt mi...@veeble.han.de (Michael Zuelsdorff):

<
< 3. wie kann ich ein Programm, das forked, (fork_monitor in cp_ccom.c)
< debuggen ?
<

Breakpoint vor dem Fork, Breakpoint im Hauptprogramm (also der Teil, der
aufgerufen wird, wenn fork() != 0 zurueckliefert), beim Erreichen des ersten
Break GO, im zweiten Break warten, bis der Child ein exec() gemacht hat.

Wenn das geforkte Programm kein exec() macht, oder das Childprogramm debuggt
werden soll, gibt's leider Probleme. Ich kenne kein Unix-System, das sowas
unterstuetzt (und du brauchst Support im Kernel fuer diese Sachen).

Das Problem ist, dass der Debugger sich nur an maximal ein Programm haengen
kann, das er ausserdem selber fork()en muss, und auf dessen Textbereich nur
ein Prozess laufen darf -- andernfalls ist der Text schreibgeschuetzt und du
kannst keine Breakpoints setzen. Deshalb auch die Breakpoints oben, damit
waehrend der Forkerei nichts passiert, das den Debugger durcheinanderbringen
koennte. Die meisten reagieren ziemlich schlecht auf solche Ereignisse.

--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/

[Markus Wild]

In article <V/T8h8...@nostromo.sub.org> rip...@nostromo.sub.org writes:
>In <1992Jan01.1...@veeble.han.sub.org>, Michael Zuelsdorff writes:
>] 3. wie kann ich ein Programm, das forked, (fork_monitor in cp_ccom.c)
>] debuggen ?
>
>Das wuesste ich auch gerne :-(

Aeh, haengt ja wohl vom verwendeten Unix ab, aber wenn Dein gdb attachen
kann, sollte das Problem ja keins sein, oder? Laesst einfach den Prozess
nach dem fork() auf pause() auflaufen, attach'st Dich an ihn, und schickst
ihm das Signal, dann gehts weiter ;-)

>Und wann gibt es endlich einen gdb-frontend, der unter X11R5 laeuft ?
>Seit dem Update auf R5 haben wir in der Uni keinen xxgdb mehr :-(

Ein Bughaufen weniger;-) Mag ja ein ketzerischer Vorschlag sein, wenn Du
ein vi-User bist, aber hast Du mal den gdb-Mode von Emacs probiert?? Ich
finde damit laesst sich sehr bequem gdb'en, auch unter X11R5 ;-)

-Markus
--
Markus M. Wild - mw...@iiic.ethz.ch | wi...@nessie.cs.id.ethz.ch
A transistor protected by a fast-acting fuse will protect the fuse by
blowing first.