[omniNotify] Core dump of notifd

['Mark Zimmerman']

I rebuilt it (from the April 13 snapshot) this way on a linux intel
box and I am running it there under valgrind. If all goes well I will
let you know tomorrow morning. If things go badly I might let you know
sooner. My application uses structured push suppliers and consumers so
I cannot comment on how anything else works.

Here is a typical 5 minute report:

======================================================================
  The following report generated by Report thread 13
    (last ReportingInterval = 300 secs)
======================================================================
  omniNotify delta stats report for Channel 0
======================================================================
queue sizes: global 127 proxy 0 notif 0
        DELTA: #announ 206 #notifs 978 #rdi_match 978 #rvm_evals 978
               time 300543 msecs : 0.685426 a/sec 3.25411 n/sec 3.93954 a+n/sec
        CUM:   #announ 797 #notifs 2633 #rdi_match 2762 #rvm_evals 2762
               time 902087 msecs : 0.883507 a/sec 2.91879 n/sec  3.80229 a+n/sec

NUM_THREAD_ID_BUCKETS for_announ 21 for_notif 4 rdi_match 2 rvm_evals 2
SAMPLED_QUEUE_SIZES glob_arriv_Q 127 proxy_work_Q 0 avg_notif_Q  0

-- Mark

On Tue, Apr 20, 2004 at 11:33:45AM -0400, Robert E. Gruber wrote:
> Up until now I have not wanted NDEBUG to be the default, since it disables a lot of
> things, including the debug log, which gives clues as to anything that is going wrong.  So
> NDEBUG has not really been thoroughly tested, though it does appear to work fine on the
> costnotify_tests. 
> 
> If Mark (and anyone else!) could try building with all three things commented out in
> DEBUG.mk, as in:
> 
> # (1) Uncomment the following to enable use of the debug log.
> #EnableDebugLog = 1
> 
> # (2) Uncomment the following to disable object garbage collection
> #DisableObjGC = 1
> 
> # (3) Uncomment the following to compile with extended debugging info (-g compile option)
> #     Only works for Unix platforms.
> #EnableDashG = 1
> 
> and use the resulting notifd it in your system, that would give me more confidence that
> NDEBUG does not break anything.  
> 
> BTW I would do a 'gmake veryclean' after the DEBUG.mk change just to make sure everything
> is rebuilt.
> 
> -- Bob
> 
> 
> 
> -----Original Message-----
> From: omninotify-list-bounces at omniorb-support.com
> [mailto:omninotify-list-bounces at omniorb-support.com] On Behalf Of 'Mark Zimmerman'
> Sent: Tuesday, April 20, 2004 10:06 AM
> To: Robert E. Gruber
> Cc: omninotify-list at omniorb-support.com
> Subject: Re: [omniNotify] Core dump of notifd
> 
> Ah, the old "bug in the debug code" problem. 
> 
> In the formal release, will NDEBUG be set by default or should I
> consider setting it explicitly. It appears that if I had set it then
> there would not have been a crash.
> 
> -- Mark
> 
> On Mon, Apr 19, 2004 at 11:32:54AM -0400, Robert E. Gruber wrote:
> > I think you found a bug in the RDI_OplockEntry debugging code: it (incorrectly) assumes
> it
> > never sees a null pointer.  I will test a fix, check it in, and then retag.  (I was just
> > tagging 2.0 today!)
> > 
> > -- Bob
> > 
> > 
> > -----Original Message-----
> > From: omninotify-list-bounces at omniorb-support.com
> > [mailto:omninotify-list-bounces at omniorb-support.com] On Behalf Of Mark Zimmerman
> > Sent: Monday, April 19, 2004 11:04 AM
> > To: omninotify-list at omniorb-support.com
> > Subject: [omniNotify] Core dump of notifd
> > 
> > Greetings:
> > 
> > notifd crashed for me last weekend; I am running a very recent
> > snapshot of omniORB and omniNotify built with gcc-3.3.3 in a Solaris 8
> > Sun Ultra 60. A traceback is appended below.
> > 
> > Since it is not obvious to me how StructuredProxyPushSupplier_i::has_events
> > calls RDI_VoidRank, I am posting this while I keep looking at it. Any
> > insights would be appreciated.
> > 
> > -- Mark
> > 
> > #0  0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0
> > (gdb) where
> > #0  0xff2d0964 in RDI_VoidRank () from /opt/omni-040413/lib/libCOSNotify4.so.0
> > #1  0xff299014 in StructuredProxyPushSupplier_i::has_events ()
> >    from /opt/omni-040413/lib/libCOSNotify4.so.0
> > #2  0xff2a5858 in virtual thunk to StructuredProxyPushSupplier_i::has_events(unsigned
> > long*, unsigned long*) () from /opt/omni-040413/lib/libCOSNotify4.so.0
> > #3  0xff2b01cc in RDI_NotifyConsumer::_next_available ()
> >    from /opt/omni-040413/lib/libCOSNotify4.so.0
> > #4  0xff2afee4 in RDI_NotifyConsumer::notify ()
> >    from /opt/omni-040413/lib/libCOSNotify4.so.0
> > #5  0xff2aee1c in RDI_NotifyBoundWorker::run_undetached ()
> >    from /opt/omni-040413/lib/libCOSNotify4.so.0
> > #6  0xff0e2d84 in omni_thread_wrapper ()
> >    from /opt/omni-040413/lib/libomnithread.so.3
> > #7  0xfe5e58c8 in _lwp_start () from /usr/lib/lwp/libthread.so.1
> > 
> > 
> > _______________________________________________
> > omninotify-list mailing list
> > omninotify-list at omniorb-support.com
> > http://www.omniorb-support.com/mailman/listinfo/omninotify-list
> > 
> 
> _______________________________________________
> omninotify-list mailing list
> omninotify-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omninotify-list
>