Menu
▾
▴
#1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
The IMM server side (IMMND and IMMD) should behave consistently and follow
a consistent coding pattern for dealing with the case of failure to allocate
memory.
Failure to allocate memory in the server is rare and means that the the processor
where the server is executing is overloaded. The server is for all practical
purposes doomed. The best behavior for this case is for the server to terminate.
The alternative of continuing but failing to provide the service is more likely
to complicate the situation than help. Escalation becomes clearer, faster and
simpler if the imm server fails fast in this case.
In terms coding, the simplest solution possible should be used. The allowed
solutions in coding on the server side should be:
a) osafassert the pointer after malloc/calloc/strdup....
b) Nothing, i.e. segv at the next dereference.
where (a) is recommended, but (b) allowed.
Writing explict code for checking for null, writing syslog error messages etc
is not allowed in the server. Less code is better in this case. The server side
must not have code for returning ERR_NO_MEMORY to the client.
one option is, as imm is implemented in c++ to call
std::set_new_handler(new_handler) in main and use new/delete instead of
malloc/free. Then if calls to new fails the new_handler will be called,
so no error checking has to be done around the new calls, amfd uses this pattern.
Yes perhaps, but what would the advantage be ?
More to the point: what is the behavior of 'new' in case of failure to obtain memory ?
I would assume some kind of assert.
/AndersBj
From: hano [mailto:hansnordeback@users.sf.net]
Sent: den 24 mars 2015 16:05
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
one option is, as imm is implemented in c++ to call
std::set_new_handler(new_handler) in main and use new/delete instead of
malloc/free. Then if calls to new fails the new_handler will be called,
so no error checking has to be done around the new calls, amfd uses this pattern.
[tickets:#1268]http://sourceforge.net/p/opensaf/tickets/1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
Status: unassigned
Milestone: future
Created: Tue Mar 17, 2015 09:49 AM UTC by Anders Bjornerstedt
Last Updated: Tue Mar 17, 2015 09:49 AM UTC
Owner: nobody
The IMM server side (IMMND and IMMD) should behave consistently and follow
a consistent coding pattern for dealing with the case of failure to allocate
memory.
Failure to allocate memory in the server is rare and means that the the processor
where the server is executing is overloaded. The server is for all practical
purposes doomed. The best behavior for this case is for the server to terminate.
The alternative of continuing but failing to provide the service is more likely
to complicate the situation than help. Escalation becomes clearer, faster and
simpler if the imm server fails fast in this case.
In terms coding, the simplest solution possible should be used. The allowed
solutions in coding on the server side should be:
a) osafassert the pointer after malloc/calloc/strdup....
b) Nothing, i.e. segv at the next dereference.
where (a) is recommended, but (b) allowed.
Writing explict code for checking for null, writing syslog error messages etc
is not allowed in the server. Less code is better in this case. The server side
must not have code for returning ERR_NO_MEMORY to the client.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/opensaf/tickets/1268/https://sourceforge.net/p/opensaf/tickets/1268
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://sourceforge.net/auth/subscriptions
Related
Tickets: #1268
if new fails the new_handler will be called and the new_handler calls abort()
to get a core dump. An alternative could be to catch std::bad_alloc but then
the stack will be unwinded so no backtrace.
An osafassert also generates abort/coredump and also a syslog ERror message, althoug I suppose there is no
guarantee the syslog message will succeed if there is a lack of memory.
In fact I guess there is no guarantee of the coredump being generaed either in that case...
I dont think I have ever seen an occurence of the out of memory failure case so I want it to be handled as
bluntly and confined as possible.
/AndersBj
From: hano [mailto:hansnordeback@users.sf.net]
Sent: den 24 mars 2015 16:38
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
if new fails the new_handler will be called and the new_handler calls abort()
to get a core dump. An alternative could be to catch std::bad_alloc but then
the stack will be unwinded so no backtrace.
[tickets:#1268]http://sourceforge.net/p/opensaf/tickets/1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
Status: unassigned
Milestone: future
Created: Tue Mar 17, 2015 09:49 AM UTC by Anders Bjornerstedt
Last Updated: Tue Mar 24, 2015 03:05 PM UTC
Owner: nobody
The IMM server side (IMMND and IMMD) should behave consistently and follow
a consistent coding pattern for dealing with the case of failure to allocate
memory.
Failure to allocate memory in the server is rare and means that the the processor
where the server is executing is overloaded. The server is for all practical
purposes doomed. The best behavior for this case is for the server to terminate.
The alternative of continuing but failing to provide the service is more likely
to complicate the situation than help. Escalation becomes clearer, faster and
simpler if the imm server fails fast in this case.
In terms coding, the simplest solution possible should be used. The allowed
solutions in coding on the server side should be:
a) osafassert the pointer after malloc/calloc/strdup....
b) Nothing, i.e. segv at the next dereference.
where (a) is recommended, but (b) allowed.
Writing explict code for checking for null, writing syslog error messages etc
is not allowed in the server. Less code is better in this case. The server side
must not have code for returning ERR_NO_MEMORY to the client.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/opensaf/tickets/1268/https://sourceforge.net/p/opensaf/tickets/1268
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://sourceforge.net/auth/subscriptions
Related
Tickets: #1268
We have been talking about introducing an xmalloc() function for a long time, though with the current naming conventions that I have been using when adding utility functions it should probably be named osaf_malloc(). The osaf_malloc() function would be guaranteed to always be successful if it returns. I.e. if it fails it will not return, but instead log to syslog and call _Exit().
There is a ticket for adding these types of utility functions: [#777].
For C++, it is probably better to use new as Hans suggests. We should also make sure to log uncaught exceptions, that logs to syslog and generates a core dump. This will catch cases like e.g. index out of bounds exceptions in STL classes.
Related
Tickets: #777
Exception handling for c++ has a reputation of sometimes adding quite some overhead to normal processing.
In any case osafasset and just plain raw segv are acceptable in my world for the very rare problem of not being able to allocate memory.
At some point we could convert the entire server code to pure c++, but it is not the highest priority right now.
/AndersBj
From: Anders Widell [mailto:anders-w@users.sf.net]
Sent: den 25 mars 2015 09:48
To: [opensaf:tickets]
Subject: [opensaf:tickets] #1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
We have been talking about introducing an xmalloc() function for a long time, though with the current naming conventions that I have been using when adding utility functions it should probably be named osaf_malloc(). The osaf_malloc() function would be guaranteed to always be successful if it returns. I.e. if it fails it will not return, but instead log to syslog and call _Exit().
There is a ticket for adding these types of utility functions: [#777]http://sourceforge.net/p/opensaf/tickets/777.
For C++, it is probably better to use new as Hans suggests. We should also make sure to log uncaught exceptions, that logs to syslog and generates a core dump. This will catch cases like e.g. index out of bounds exceptions in STL classes.
[tickets:#1268]http://sourceforge.net/p/opensaf/tickets/1268 IMM: Server side behavior at failure to allocate memory needs to be consistent
Status: unassigned
Milestone: future
Created: Tue Mar 17, 2015 09:49 AM UTC by Anders Bjornerstedt
Last Updated: Tue Mar 24, 2015 03:38 PM UTC
Owner: nobody
The IMM server side (IMMND and IMMD) should behave consistently and follow
a consistent coding pattern for dealing with the case of failure to allocate
memory.
Failure to allocate memory in the server is rare and means that the the processor
where the server is executing is overloaded. The server is for all practical
purposes doomed. The best behavior for this case is for the server to terminate.
The alternative of continuing but failing to provide the service is more likely
to complicate the situation than help. Escalation becomes clearer, faster and
simpler if the imm server fails fast in this case.
In terms coding, the simplest solution possible should be used. The allowed
solutions in coding on the server side should be:
a) osafassert the pointer after malloc/calloc/strdup....
b) Nothing, i.e. segv at the next dereference.
where (a) is recommended, but (b) allowed.
Writing explict code for checking for null, writing syslog error messages etc
is not allowed in the server. Less code is better in this case. The server side
must not have code for returning ERR_NO_MEMORY to the client.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/opensaf/tickets/1268/https://sourceforge.net/p/opensaf/tickets/1268
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://sourceforge.net/auth/subscriptions
Related
Tickets: #1268
Tickets: #777