AnsweredAssumed Answered

FW: SICL, shared libraries and forks

Question asked by VRFuser on Dec 1, 1997
>
> Hi Greg,
>
> Is basic@lvld.hp.com still the right address to send requests like this
> too? If not, is there a better one?

BASIC is fine.  Thanks, Lee.

> Thanks.
>
>                -lee
>
> > -----Original Message-----
> > From:     Lee Atchison
> > Sent:     Tuesday, December 02, 1997 7:41 AM
> > To:     'Doug Olney'
> > Cc:     Greg Goebel (E-mail); Jay Johannes; 'basic@lvld.hp.com'; Lee
> > Atchison
> > Subject:     RE: SICL, shared libraries and forks
> >
> > Hi Doug,
> >
> > Please go through our support organization, they are better equiped to
> > handle problems like this. You can reach them at basic@lvld.hp.com.
> > They have the support contacts within my R&D group to call upon, if
> > necessary, to help fix your problem.
> >
> > Hope this helps.
> >
> >                -lee
> >
> > -----Original Message-----
> > From:     Doug Olney [SMTP:olney@sr.hp.com]
> > Sent:     Monday, December 01, 1997 11:56 AM
> > To:     lee@lvld.hp.com
> > Cc:     drm@sr.hp.com
> > Subject:     SICL, shared libraries and forks
> >
> >
> > Hello Lee,
> >
> > My name is Doug Olney.  I am an engineer at Santa Rosa Systems
> > Division
> > working on the HP 84000 - a big test system for cellular phone IC's.
> > Can
> > you help me with a bizarre SICL problem we are having?  Basically,
> > we have found a sequence that causes SICL to unmap a shared memory
> > block we are using, causing a SIGSEV the next time we go to talk
> > to that VXI card.
> >
> > The sequence is this:
> >   
> >   0) System started, communication established with all instruments,
> >       a variety of HP-IB and MXI/VXI instruments.  imap used to share
> >       memory with a pair of e1430a digitizers.
> >   1) Load a shared library containing a test plan.  A test plan is
> >       a C++ object that boils down to a single member function that
> >       calls the measurement and stimuli in the order required.
> >   2) Run the test plan.
> >   3) In an effort to launch a subroutine to babysit a plot (no
> > hardware
> >       access, data via stdin), we vfork and execlp in an effort to let
> >       the shell find the plot executable.  This fails, and seeds
> > something
> >       that irritates SICL, although SICL doesn't act yet.
> >   4) We try again, this time using vfork and execl to a specific
> > system
> >        executable that is known to exist.  This succeeds, plot
> > appears.
> >   5) At this point, the system appears fine.  I can take data, access
> >        instruments, write shared memory, whatever.  I can even repeat
> >        (3) and (4) as many times as I like.
> >   6) Done testing. The testplan finishes.  We destroy the object and
> >        unload the shared library.
> >   7) As soon as the call to cxxunload comes back, the shared memory
> > allocated
> >        to talk to e1430 on VXI is unmapped.  The next time I go to
> > access
> >        that memory, SIGSEV.
> >
> > However, by removing step (3), the system is as happy as a clam.  I
> > can
> > load/unload and plot to my heart's content.
> >
> > Another other oddity to this is that the executable must be optimized.
> >
> > It doesn't happen when debug symbols are present.
> >
> > Our system is on UNIX 10.20, running on 745's, with SICL Version
> > E.01.01.
> > We have just fielded our 50'th system, so we take this issue very
> > seriously.
> >
> > So, questions I would like answers too:
> >
> >   1) Did I trip on some wierd localized effect that is safely removed
> >      by removing step (3) above, or is this an evil lurking beneath
> > the
> >      surface that is going to arise again?
> >
> >   2) By what mechanism does SICL remember the failed fork/exec and
> > unmap
> >      the session when the shared library unloads?
> >
> > Thanks!
> >
> > Doug Olney
> > Santa Rosa Systems Division
> > 1-577-49094

Outcomes