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. > I did some more tests. I now disabled newtrace() at all, by adding > return; as the first command in this function. > > That helped a little bit. > > It may save some performance if newtrace() does not do any processing, > if trace_level is set 0. I think the function can simply return if > trace_level is set to 0. Now in SVN. > When ever i have a look at the backtraces, is has always something to do > with g_strdup_vprintf. That's where everything goes wrong. > > Seems like we need to debug glib a little bit more. :-( If you are on Solaris, are you using the Solaris null pointer workaround? Aaron
