[Bug translator/22278] New: the nss client code doesn't handle '-I DIR' well

[Bug translator/22278] New: the nss client code doesn't handle '-I DIR' well

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

            Bug ID: 22278
           Summary: the nss client code doesn't handle '-I DIR' well
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: dsmith at redhat dot com
  Target Milestone: ---

Using a custom tapset directory works fine:

====
# cat tapset/foo.stp
function foo()
{
        printf("Hello\n")
}
# stap -I tapset -e 'probe oneshot { foo() }'
Hello
====

However, if you try to do the same thing with a compile server, you get an
error:

====
# stap --use-server -I tapset -e 'probe oneshot { foo() }'
semantic error: unresolved function (similar: log, HZ, pn, pp, cpu): identifier
'foo' at <input>:1:17
        source: probe oneshot { foo() }
                                ^

WARNING: unused command line option $1/@1
Pass 2: analysis failed.  [man error::pass2]
Passes: via server failed.  Try again with another '-v' option.
====

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22278] the nss client code doesn't handle '-I DIR' well

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fche at redhat dot com

--- Comment #1 from Frank Ch. Eigler <fche at redhat dot com> ---
The http client/server pair should try to handle this case (maybe by zipping up
that -I path).  Wouldn't worry about the old client/server.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22278] the nss client code doesn't handle '-I DIR' well

[brolley at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

Dave Brolley <brolley at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brolley at redhat dot com

--- Comment #2 from Dave Brolley <brolley at redhat dot com> ---
The old client/server should already handle this, by zipping up the -I
directories, exactly as you have suggested.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22278] the nss client code doesn't handle '-I DIR' well

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

--- Comment #3 from David Smith <dsmith at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #1)
> The http client/server pair should try to handle this case (maybe by zipping
> up that -I path).  Wouldn't worry about the old client/server.

The nss client/server does handle this case, it just doesn't handle it well. It
does copy the tapset directory over, but mangles the command line. If I'm
reading the "client" directory correctly, with --use-server the stap command
line that goes over to the server ends up looking like:

# stap tapset/home/dsmith/tapset -I tapset -v -e 'probe oneshot { foo() }'

which is clearly wrong.

The http client/server shares code/ideas with the nss client/server, and I'm
sure the same problem exists in the http client/server. I was wondering how the
nss client/server handled this when I found the problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22278] the nss client code doesn't handle '-I DIR' well

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

--- Comment #4 from David Smith <dsmith at redhat dot com> ---
(In reply to Dave Brolley from comment #2)
> The old client/server should already handle this, by zipping up the -I
> directories, exactly as you have suggested.

Right, but nss_client_backend::include_file_or_directory() is always adding an
included file/diretory to the command line, which isn't correct.

(It is certainly possible I introduced this bug when I generalized the client
code to be able to include the http code.)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22278] the nss client code doesn't handle '-I DIR' well

[brolley at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

--- Comment #5 from Dave Brolley <brolley at redhat dot com> ---
IIRC, the modified command line was deliberate and it is supposed to be
suitable for finding the unzipped -I directories on the server side.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22278] the nss client code doesn't handle '-I DIR' well

[dsmith at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22278

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from David Smith <dsmith at redhat dot com> ---
This worked in 3.1. Commit 586c8666a, which split up the client functionality,
caused this bug. Test added so that we'll hopefully notice if this breaks
again. Fixed in commit 504364331

-- 
You are receiving this mail because:
You are the assignee for the bug.