>
> 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
> 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