Linux-Development-Sys Digest #322, Volume #8 Mon, 4 Dec 00 17:13:15 EST
Contents:
Re: A challenging problem... (Duane Rettig)
Re: A challenging problem... (Kaelin Colclasure)
Re: Autoconfiscating a loadable module (Kaelin Colclasure)
VMX support ? (Nilesh Patel)
Re: A challenging problem... (Frode Vatvedt Fjeld)
Re: A challenging problem... (Kaelin Colclasure)
Linux Sockets, SendQ buffer problem! ([EMAIL PROTECTED])
Development Environments ("Guy Dillen")
Re: Problems with (XDR)-Headers (Lavrentios Servissoglou)
Re: Linux Sockets, SendQ buffer problem! (Kaelin Colclasure)
----------------------------------------------------------------------------
From: Duane Rettig <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: Re: A challenging problem...
Date: 04 Dec 2000 08:44:10 -0800
Kaelin Colclasure <[EMAIL PROTECTED]> writes:
> My problem lies in how to implement
> dynamic probe support. Solaris' prex has the equivalent of this
> feature, but only for C programs. I suspect prex implements it by
> scanning the ELF executable files for certain signature data
> associated with each embedded probe.
The problem is one of how to identify the probe. The common type of
probe is a breakpoint in any of the debuggers that use ptrace (e.g.
dbx, gdb ...) and these are usually specified either by address or by
symbol-name and offset. (Higher-level specifications include line
numbers, which count on such line number information being available
and up-to-date, but these usually translate to an offset from a symbol.)
An address breakpoint may become invalidated over more than one invocation
of the executable, because a shared-library might have moved between the
end of one program and its next invocation. I have seen debuggers on
some operating systems not bother to re-establish by-address breakpoints
at the start of a new run of the program under debug, but others only
invalidate those breakpoints if the shared-library did in fact move.
It is also possible to dynamically load and unload shared-libraries
during normal program execution, but I am not sure what ptrace
implementations do with these dynamics.
The above C-style scenario is predicated on a shared-library being
a module which, if it moves, moves as a unit, and not very often.
The problem/feature of lisp is that it is the _function_'s code
which is a dynamic unit which might move all on its own.
Breakpoints or probes must be identified within the lisp by
function and offset, and not by address. Also, the code is much
more likely to move, since it is in most cases simply lisp data
in some form of vector. So the probe mechanism must consult the
lisp under test for the exact identity of the probe, because
otherwise the address it sees is arbitrary.
Allegro CL has a mechanism called "lldb" (lisp low-level debugger)
which sets breakpoints at the instruction level and responds to
them to provide an instruction stepper. The mechanism existed in
5.0.1 but has been improved in 6.0. Breakpoints are set via the
:br[eak] top-level command, and enabled via the :ldb command. A
breakpoint is identified by function and pc-offset.
Unfortunately, the lldb facility as of yet has no hooks to provide
for general probing. I suppose such hooks could be added in the
future.
> I'm pretty sure prex enables and
> disables the probes by poking data into the traced processes' data
> segment in memory. Not trivial, but not rocket science. But it relies
> on the fact that in C it's relatively straightforward to affect the
> layout of the processes' text and data segments (e.g. to embed the
> probe signatures) in a predictable way.
> Now, the question is how best to approach this feature given that I
> also want to support dynamic probes for Common Lisp -- and in general
> to come up with a technique that can be made to work for languages
> that don't allow you to approximate the behavior of an assembler. (Java
> would of course be another example.)
If you also want to hook an interpreter, you would need support for this.
I don't know what Java provides. CLtL1 defined hook variables *evalhook*,
*applyhook*, and some other functionality to to this. X3J13 removed these,
so CL doesn't have them. However, some implementations may retain this
functionality as backward compatibility. (Allegro CL provides for this)
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 [EMAIL PROTECTED] (internet)
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: Re: A challenging problem...
Date: 04 Dec 2000 09:16:49 -0800
Frode Vatvedt Fjeld <[EMAIL PROTECTED]> writes:
> Kaelin Colclasure <[EMAIL PROTECTED]> writes:
>
> > [...] My problem lies in how to implement dynamic probe
> > support. Solaris' prex has the equivalent of this feature, but only
> > for C programs. I suspect prex implements it by scanning the ELF
> > executable files for certain signature data associated with each
> > embedded probe.
>
> You might want to look at the Paradyn research project. They're
> basically dealing with exactly these issues, and have even implemented
> dynamic instrumentation of OS kernels. <URL:http://www.cs.wisc.edu/~paradyn/>
Ah, interesting. I was aware of IBM's dProbes project for Linux.
(Thanks to another poster here on c.o.l.d.s.) I suspect these efforts
are related -- or at least collaborating at some level.
>From the presentation materials available on their site, it appears
they're using symbol table information from the executables in order
to target their dynamic code modifications.
> I have written some code (in common lisp) for attaching to processes
> and allocating buffers inside them, and like you say, it's not really
> rocket science.
Did you use their dyninst API?
> > Less byzantine suggestions (that still meet the constraints) are
> > welcome. :-)
>
> While hack'n slash approaches like machine-code modification via
> ptrace/procfs come naturally in a C world, I'm not so sure they are
> appropriate for dynamic languages like lisp. I think it'd be smarter
> to have the lisp runtime system much more involved in the
> instrumentation and tracing process. But this suggestion doesn't
> exactly solve your problem..
Paradoxically, dynamic instrumentation of the product of a static
language by an external agent is relatively straightforward. Precisely
because the language itself is static, it eventually all comes down to
specific offsets into the program's text segment.
But of course, dynamic instrumentation is trivially supported in
Common Lisp if the agent itself lives in the same Lisp image. In fact,
advice, tracing and several other Common Lisp features are built on
this capability.
Hmmm, perhaps the only realistic way to adequately support such
dynamic languages is to collaborate with their native capabilities
rather than trying to second-guess them. Maybe I need to rethink my
assertion that all higher-level IPC functions are verboten. But one
motivation for that restriction was to minimize the amount of noise
incurred if system call tracing was enabled along with embedded
probes...
[Scratching head.] Maybe the whole premise of poking into the
processes' address space is flawed...
-- Kaelin
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Subject: Re: Autoconfiscating a loadable module
Date: 04 Dec 2000 09:26:37 -0800
"Peter T. Breuer" <[EMAIL PROTECTED]> writes:
> Kaelin Colclasure <[EMAIL PROTECTED]> wrote:
> > Has anyone devised a workable configuration for having a Linux
> > loadable kernel module compiled and installed using the standard GNU
> > autoconf tools? I'm in the process of "autoconfiscating" OpenTNF
>
> No. Though I think I'm practised enough that I could do it easily. I mean,
> all you have to do is compile the module and install it in
> /lib/module/`uname -r`/blah, watching out for if the source and running
> kernel match.
And I figured that out, eventually. :-) In the process I also wrote a
couple of autoconf macros, which I've submitted to the autoconf macro
archive: <http://research.cys.de/autoconf-archive/>
But these really just scratch the surface. It would be nice to have
automake support as well, and have autoconf test that your kernel
headers match your running kernel, and... well, you get the idea.
Any takers? :-)
-- Kaelin
------------------------------
From: Nilesh Patel <[EMAIL PROTECTED]>
Subject: VMX support ?
Date: Tue, 05 Dec 2000 10:03:53 +0530
Does any flavour of Linux support save/restore of VMX context ?
Is there any project going on for this ?
Nilesh
------------------------------
From: Frode Vatvedt Fjeld <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: Re: A challenging problem...
Date: 04 Dec 2000 20:47:35 +0100
> Frode Vatvedt Fjeld <[EMAIL PROTECTED]> writes:
>
> > I have written some code (in common lisp) for attaching to processes
> > and allocating buffers inside them, and like you say, it's not really
> > rocket science.
Kaelin Colclasure <[EMAIL PROTECTED]> writes:
> Did you use their dyninst API?
No, it's built atop procfs for FreeBSD (differences to linux should be
minimal). I basically abandoned it as a research track when I
discovered Paradyn etc. :)
> Paradoxically, dynamic instrumentation of the product of a static
> language by an external agent is relatively
> straightforward. Precisely because the language itself is static, it
> eventually all comes down to specific offsets into the program's
> text segment.
But the potential quality of information that can be extracted from
lisp is much greated than that of C, I think.
In practical terms, I'd guess you could use the lisp's FFI to install
a gateway into the dynamic lisp world. I believe for example Allegro's
FFI will create static entries (function entries and other objects
that are guaranteed not to be moved by GC) to lisp in order to
accommodate calling lisp functions from C.
> But of course, dynamic instrumentation is trivially supported in
> Common Lisp if the agent itself lives in the same Lisp image. In
> fact, advice, tracing and several other Common Lisp features are
> built on this capability.
Yes, and I'd say you should think very carefully before you throw away
all this. The ptrace stuff is a necessity in C, but that doesn't mean
it's desirable in lisp.
> Hmmm, perhaps the only realistic way to adequately support such
> dynamic languages is to collaborate with their native capabilities
> rather than trying to second-guess them. Maybe I need to rethink my
> assertion that all higher-level IPC functions are verboten. But one
> motivation for that restriction was to minimize the amount of noise
> incurred if system call tracing was enabled along with embedded
> probes...
There are contradictory goals of low intrusion and quality of
extracted information. (Ideally, the user should be able to chose
which is preferred.) But the situation is rather different in lisp and
C. Lisp images are much more soundly constructed, and with good
introspective capabilities (and dynamism), which means you can do lots
of stuff (high-level or whatever) with only some performance intrusion
(i.e. a slow-down, but practically no functional intrusion; the
program still works exactly the same).
> [Scratching head.] Maybe the whole premise of poking into the
> processes' address space is flawed...
Most any instrumentation scheme can be seen as "poking in processes'
address space", but this activity must be based on some set of
assumptions about the image. These assumptions typically stem from the
CPU architecture, OS conventions and the compiler that produced the
code (function calling conventions, for example). The nature of these
assumptions is quite different for C and lisp images.
--
Frode Vatvedt Fjeld
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.lisp
Subject: Re: A challenging problem...
Date: 04 Dec 2000 12:03:14 -0800
Duane Rettig <[EMAIL PROTECTED]> writes:
> Kaelin Colclasure <[EMAIL PROTECTED]> writes:
>
> > My problem lies in how to implement
> > dynamic probe support. Solaris' prex has the equivalent of this
> > feature, but only for C programs. I suspect prex implements it by
> > scanning the ELF executable files for certain signature data
> > associated with each embedded probe.
>
> The problem is one of how to identify the probe. The common type of
> probe is a breakpoint in any of the debuggers that use ptrace (e.g.
> dbx, gdb ...) and these are usually specified either by address or by
> symbol-name and offset. (Higher-level specifications include line
> numbers, which count on such line number information being available
> and up-to-date, but these usually translate to an offset from a symbol.)
> An address breakpoint may become invalidated over more than one invocation
> of the executable, because a shared-library might have moved between the
> end of one program and its next invocation. I have seen debuggers on
> some operating systems not bother to re-establish by-address breakpoints
> at the start of a new run of the program under debug, but others only
> invalidate those breakpoints if the shared-library did in fact move.
> It is also possible to dynamically load and unload shared-libraries
> during normal program execution, but I am not sure what ptrace
> implementations do with these dynamics.
That's a good point. I'm pretty sure prex scans the ELF executable
for .so dependencies and recursively loads and scans all of them for
probes as well -- but I don't know *what* it does when the code
dlopen's a .so that contains probes. Probably nothing. :-/
Hmmm, let's hypothesize for a bit that I've become convinced that in
order to do dynamic probe support properly, some responsibility is
going to have to be delegated to trace aware processes. For instance
that they have to provide a catalog of their probes (somehow) and that
they have to implement some primitive mechanism for enabling and
disabling them under trex's control. What primitive mechanisms will
interact well (or at least predictably) with Common Lisp? For
instance, if I implement a signal handler in a supporting .so, can it
safely call out to Lisp code exposed by the FFI layer?
[...]
> > Now, the question is how best to approach this feature given that I
> > also want to support dynamic probes for Common Lisp -- and in general
> > to come up with a technique that can be made to work for languages
> > that don't allow you to approximate the behavior of an assembler. (Java
> > would of course be another example.)
>
> If you also want to hook an interpreter, you would need support for this.
> I don't know what Java provides. CLtL1 defined hook variables *evalhook*,
> *applyhook*, and some other functionality to to this. X3J13 removed these,
> so CL doesn't have them. However, some implementations may retain this
> functionality as backward compatibility. (Allegro CL provides for this)
At the point interpreted code comes into the picture, I see little
benefit in making heroic efforts to enable dynamic probe support at
the level of the traced process. It's much simpler (and possibly even
more efficient) to eat the system call and then let the driver decide
whether to keep the probe data or not. I call this style of probe a
"Compatible String Probe" or CSP. The (perceived, by me at least)
problem with CSP's is that they're relatively expensive. They incur
the expense of a system call and parsing at the driver level whether
enabled or not -- e.g. you pay for them even when you're not using
them. In general that's something I'm trying hard to avoid.
-- Kaelin
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking
Subject: Linux Sockets, SendQ buffer problem!
Date: Mon, 04 Dec 2000 21:16:42 GMT
Reply-To: [EMAIL PROTECTED]
My programmer wrote a TCP test application here to test the connectivity
and behavior of sudden TCP disconnections between the client and server
and compiled it for several operating systems including Linux, FreeBSD,
and windoze. We created this to confirm our results of server apps
hanging and that there may be a Linux problem associated with this.
The versions that the software is compiled on are Linux 2.2.17 and
FreeBSD 4.1.
The tcpTest application just sends 4K packets of data every 5 seconds to
the client and the client acknowledges this.
What we did was to run the program tcpTest on both the Linux and BSD
machines. Then lanch the windoze client to connect to both the Linux
and BSD "servers" as well...
This is some of the output of what happens...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
This is the output from both servers.
The test is now to see how a sudden disconnect (unplug the network
cable) is handled by both servers.
Here are those results...
on the freeBSD machine....
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
fd(6) Send Fails - dylon.roc.com:4711 disconnecting from 65535. <1>
The server process realized a disconnect after maybe 20 seconds.
on the Linux machine...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
Sending test packet of 4096 bytes to 1 proc(s) ...
But the Linux machine did not disconnect for a lot longer.
Here is the netstat sendQ results too.
FreeBSD...
tcp 0 16384 192.22.2.101.65535 192.22.2.47.4711 FIN_WAIT_1
tcp 0 16384 192.22.2.101.65535 192.22.2.47.4711 FIN_WAIT_1
tcp 0 16384 192.22.2.101.65535 192.22.2.47.4711 FIN_WAIT_1
It seems to disconnect and the sendQ's which are the 16384 column never
seem to keep increasing which tells me that the server has recognized
that the client has disconnected.
Linux...
tcp 0 20480 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
tcp 0 24576 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
tcp 0 28672 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
tcp 0 32768 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
tcp 0 40960 192.22.2.124:65535 192.22.2.47:4601 ESTABLISHED
etc...
Up to 56K bytes on the sendQ
*** Once it reaches that 56K mark it just hangs to process!
So it means that the Linux server never realizes that the client went
away and thus keeps trying to send messages to it.
This is one problem. The other problem is that when there is a
disconnect and you kill the server process at this point, and try to
restart it, you cannot re-publish the port because now you are in
FIN_WAIT_1 state and then in TIME_WAIT states.
It seems to take a long time for these states to clear up both on
FreeBSD and Linux. Thus, you can not get the tcpTest server restarted
until the process is cleared. Is there some way to fix this?
I'd be glad to send this test program to anyone willing to try and see
my results for themselves.
Maybe there is some IOCTL call that needs to be made in order to close
the socket properly?
Any help is greatly appreciated.
Jim
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Guy Dillen" <[EMAIL PROTECTED]>
Subject: Development Environments
Date: Mon, 4 Dec 2000 22:31:17 +0100
What is/are the most used development environments on Linux for database
based applications?
Guy Dillen
E-mail [EMAIL PROTECTED]
------------------------------
From: Lavrentios Servissoglou <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Problems with (XDR)-Headers
Date: Mon, 4 Dec 2000 22:39:58 +0100
Eric G. Miller wrote:
> In article <90bjau$gfeh$[EMAIL PROTECTED]>, "Lavrentios
> Servissoglou" <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > I want to use the XDR macros (routines) to "translate" OS specific data
> > types to OS independent format and vice versa. The problem I have with
> > Linux is to find the appropriate header files. I've tried it with
> > "rpc/rpc.h", "rpc/xdr.h" and a lot of other combinations. Every time the
> >
> > compiler (g++ (egcs)) complains problems with data types defined in
> > theses header files. Does anyone know the magic sequence and
> > combination of appropriate header files.
>
> I think you want rpc/types.h.
Thank you for your help.
"rpc/rpc.h" includes "rpc/types.h". Even if I include "rpc/types.h"
explicitely, I get the same whole bunch of type errors in these include
files. I use RedHat 6.2, maybe this provides more information. At the
moment I use an "overheaded" circumvention: I build my transfer buffers
with sprintf()/sscanf(). What a mess.
Again, thanks in advance.
Lavrentios Servissoglou
([EMAIL PROTECTED])
------------------------------
From: Kaelin Colclasure <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Linux Sockets, SendQ buffer problem!
Date: 04 Dec 2000 13:52:21 -0800
[EMAIL PROTECTED] writes:
> My programmer wrote a TCP test application here to test the connectivity
> and behavior of sudden TCP disconnections between the client and server
> and compiled it for several operating systems including Linux, FreeBSD,
> and windoze. We created this to confirm our results of server apps
> hanging and that there may be a Linux problem associated with this.
>
> The versions that the software is compiled on are Linux 2.2.17 and
> FreeBSD 4.1.
>
> The tcpTest application just sends 4K packets of data every 5 seconds to
> the client and the client acknowledges this.
Does "your programmer" actually check the result of the send call?
Based on the FreeBSD output I would assume "yes", but sometimes it
pays not to assume...
[...]
> on the freeBSD machine....
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> fd(6) Send Fails - dylon.roc.com:4711 disconnecting from 65535. <1>
>
>
> The server process realized a disconnect after maybe 20 seconds.
>
> on the Linux machine...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
> Sending test packet of 4096 bytes to 1 proc(s) ...
[...]
> This is one problem. The other problem is that when there is a
> disconnect and you kill the server process at this point, and try to
> restart it, you cannot re-publish the port because now you are in
> FIN_WAIT_1 state and then in TIME_WAIT states.
>
> It seems to take a long time for these states to clear up both on
> FreeBSD and Linux. Thus, you can not get the tcpTest server restarted
> until the process is cleared. Is there some way to fix this?
See SO_REUSEADDR.
-- Kaelin
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
