[omniNotify] Core dump of notifd

[Robert E. Gruber]

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