In general, assert failures occur when a condition that can't happen actually happens. A particular pointer can't under any circumstance be NULL but it is, the timestamps on a page can't be different but they are. Even though you don't want to see an 'Assert failure' they are the good guys, without the failure the data would probably have been corrupted.
Assertions are not a mechanism for handling run-time errors. For example, an assertion violation caused by the user inadvertently entering a negative number when a positive number is expected is poor program design. Cases like this must be handled by appropriate error-checking and recovery code (such as requesting another input), not by assertions.
Realistically, of course, programs of any reasonable size do have bugs, which appear at run-time. Exactly what conditions are to be checked by assertions and what by run-time error-checking code is a design issue. Assertions are very effective in reusable libraries, for example, since the library is small enough for it to be possible to guarantee bug-free operation, and the library routines cannot perform error-handling because they do not know in what environment they will be used.
At higher levels of a program, where operation is more complex, run-time error-checking must be designed into the code.
Every time the database accesses a buffer it runs a function called bfcheck to verify the buffer. There is an assertion on this function, e.g. the page that was requested is the page that was returned. When an assert failure happens there will be a message in the online logfile.
1: Assert Failed: Page Check Error in phposition:isfirst:bad page
Informix Dynamic Server 2000 Version 9.21.UC4
2: Who: Session(69,informix@eric,67234,272271956)
Thread(28,sqlexec, d66a7e8,1)
File: rsdebug.c Line:1038
3: Results: Possible inconsistencies in eric:"eric".table
Action: Run 'oncheck -cDI eric:"eric".table'
4: stack trace for pid 67324 written to /var/tmp/af.5678249
See Also: /var/tmp/af.5678249, shmem.5678249.0
The two lines states that there was a bad page and confirms the version of the database server.
Next the session information for the session that generated the assert failure. Session 69 was run by informix on the machine eric. The process ID was 67324 and the userthread ID was 28 and was an sqlexec, i.e. the typical user thread type for client applications. Just because this session caused the assert failure doesn't mean that the session was the cause of the problem.
Next the relevant table information is displayed and a recommended cause of action i.e. oncheck -cDI eric:"eric".table
The final part of the output states where further information can be found. The onstat command can be run against the shmem file.
#include <stdio.h>
void assertfail(const char *expr, const char *filename, int linenum);
void assertfail(const char *expr, const char *filename, int linenum)
{
(void)fprintf(stderr,"dbassert: in file %s line %d\n",filename,linenum);
(void)fprintf(stderr," expr: %s\n",expr);
exit(1);
}
By using your own version of assert.h and including it in the relevant modules you can prevent the standard assert implementation from being executed
#ifndef _ASSERT_H #define _ASSERT_H #pragma ident "%A" extern void assertfail(const char *, const char *, int); #endif /* _ASSERT_H */ /* * Note that the ANSI C Standard requires all headers to be idempotent except *which is explicitly required not to be idempotent (section 4.1.2). * Therefore, it is by intent that the header guards (#ifndef _ASSERT_H) do * not span this entire file. */ #undef assert #ifdef NDEBUG #define assert(EX) ((void)0) #else #if defined(__STDC__) #define assert(EX) (void)((EX) || (assertfail(#EX, __FILE__, __LINE__), 0)) #else #define assert(EX) (void)((EX) || (assertfail("EX", __FILE__, __LINE__), 0)) #endif /* __STDC__ */ #endif /* NDEBUG */
To discuss how Oninit ® can assist please call on +1-913-674-0360 or alternatively just send an email specifying your requirements.