Am Montag, den 11.09.2006, 12:09 -0700 schrieb Aaron Stone: > On Mon, 2006-09-11 at 18:27 +0200, Lars Kneschke wrote: > > Am Montag, den 11.09.2006, 08:45 +0200 schrieb Paul J Stevens: > > > Lars, > > > > > > The only changes over the last week were in the FETCH code (not touched > > > in your examples), in the sqlite layer and in the pop3 code. But I've > > > also been moving a lot of the trace calls in the imap code to Aaron's > > > newtrace macros. Given that we've seen problems on solaris before in the > > > trace code, I wonder if that's the case here as well. So, could you run > > > some tests on a trace_level=0, and see if it still crashes then? > > Changing from trace to TRACE does not significantly change the behavior > of the newtrace function; it just adds the module, file, func, line > arguments into the format string. These are always non-null as far as I > can tell. > > g_strdup_printf does require the Solaris workaround in case one of its > arguments is null, so that's definitely something to look at. Can you explain that a little bit further? Do you mean /usr/lib/[EMAIL PROTECTED]
I have a c developer in my company, who should have a look at this problem later this day. > Now in SVN. Thanks! > If you are on Solaris, are you using the Solaris null pointer > workaround? You mean LD_PRELOAD_32=/usr/lib/[EMAIL PROTECTED] . Yes, i added that to our init scripts.
