Hello Martin, Many thanks for the patch. I have applied it and committed it to the SVN. It will undoubtedly spare us from a good deal of support problems :-)
Best regards, Kern On Wednesday 29 August 2007 21:01, Martin Simmons wrote: > >>>>> On Wed, 29 Aug 2007 14:35:28 +0200, Kern Sibbald said: > > > > On Wednesday 29 August 2007 12:34, Martin Simmons wrote: > > > >>>>> On Wed, 29 Aug 2007 11:34:57 +0200, Kern Sibbald said: > > > > > > > > Hello Dirk, > > > > > > > > Could you update to the latest SVN and test again? I think there is > > > > a good chance that I have fixed your problem. It was one of the > > > > possibilities on my list, but thanks to Martin's comment, I re-read > > > > the stdarg documentation and now believe that it was due to > > > > re-calling a subroutine, which trashed a critical argument pointer. > > > > > > Possibly configure needs to probe for va_copy to set HAVE_VA_COPY? > > > > Yes, I agree, but I am too tired to do it. A pain, but ... > > I've attached an autoconf patch that seems to work. I tested configure > (though not the resulting builds) on FreeBSD 4.9 & 5.4, Linux FC3 and Mac > OS X 10.4.9. The patch doesn't include the generated files. > > __Martin > > > > The build currently fails on FreeBSD 4.9 (gcc 2.95.4), which doesn't > > > have va_copy. > > > > They will undoubtedly need to manually add a #undef HAVE_VA_COPY or > > someone will need to supply a configure.in patch. > > > > > Conversely, I think va_copy *is* available on Mac OS X (Darwin) and in > > > fact would be needed for a 64-bit build (which is amd64 like Dirk's > > > Linux machine). > > > > I could not find stdarg in their man pages, so turned on the alternative, > > which should work fine. > > > > Regards, > > > > Kern > > > > > __Martin > > > > > > > Anyway, let's now hope it is fixed ... > > > > > > > > Regards, > > > > > > > > Kern > > > > > > > > On Tuesday 28 August 2007 22:48, Dirk H Bartley wrote: > > > > > On Tue, 2007-08-28 at 07:53 +0200, Kern Sibbald wrote: > > > > > > Hello Dirk, > > > > > > > > > > > > I've looked over the code, and if there is something wrong with > > > > > > it, I am certainly missing it. Perhaps someone on the devel list > > > > > > will see something that I cannot. > > > > > > > > > > > > At this point, I'm privileging a compiler bug. Could you give me > > > > > > the following information? > > > > > > > > > > > > 1. The version of the compiler and the architecture for each > > > > > > machine where you have the failure. > > > > > > > > > > These are gentoo machines. I'm getting the gcc version with: > > > > > gcc-config -l > > > > > > > > > > myth2 ~ # uname -a > > > > > Linux myth2 2.6.19-gentoo-r2 #5 SMP Thu Dec 28 22:24:13 EST 2006 > > > > > x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux > > > > > gcc x86_64-pc-linux-gnu-4.1.1 > > > > > > > > > > srvalum3 ~ # uname -a > > > > > Linux srvalum3 2.6.20-gentoo #3 SMP Sun Feb 18 12:32:04 EST 2007 > > > > > x86_64 Dual-Core AMD Opteron(tm) Processor 2210 AuthenticAMD > > > > > GNU/Linux gcc x86_64-pc-linux-gnu-4.1.1 > > > > > > > > > > > 2. The version of the compiler and the architecture for each > > > > > > machine where you do not have the failure. > > > > > > > > > > workplay ~ # uname -a > > > > > Linux workplay 2.6.17-gentoo-r5 #4 SMP Thu Apr 19 19:58:11 EDT 2007 > > > > > i686 AMD Sempron(tm) 2600+ AuthenticAMD GNU/Linux > > > > > gcc i686-pc-linux-gnu-3.4.4 > > > > > > > > > > > Could you give me the complete compile line with all the options > > > > > > for both dird/ua_output.c and lib/bsnprintf.c? Either edit the > > > > > > Makefile and remove the $(NO_ECHO) in front of the compile rules > > > > > > (the .c.o: and .cc.o: lines), or set the environment variable > > > > > > NO_ECHO to the empty string. > > > > > > > > > > Compiling ua_output.c > > > > > /usr/bin/x86_64-pc-linux-gnu-g++ -c -I/usr/include/python2.4 > > > > > -I. -I.. -O2 -march=athlon64 -pipe -g ua_output.c > > > > > > > > > > Compiling bsnprintf.c > > > > > /usr/bin/x86_64-pc-linux-gnu-g++ -c -I/usr/include/python2.4 > > > > > -I. -I.. -O2 -march=athlon64 -pipe -g bsnprintf.c > > > > > > > > > > then set makefile optimization > > > > > > > > > > Compiling bsnprintf.c > > > > > /usr/bin/x86_64-pc-linux-gnu-g++ -c -I/usr/include/python2.4 > > > > > -I. -I.. -O0 -march=athlon64 -pipe -g bsnprintf.c > > > > > > > > > > Compiling ua_output.c > > > > > /usr/bin/x86_64-pc-linux-gnu-g++ -c -I/usr/include/python2.4 > > > > > -I. -I.. -O0 -march=athlon64 -pipe -g ua_output.c > > > > > > > > > > > Could you set the compile optimization for those two files to -O0 > > > > > > (minus oh zero)? Either edit the Makefile or set it on the > > > > > > command line via a preceding environment variable setting of > > > > > > CFLAGS. Then test again and see if it fails. > > > > > > > > > > Yes it fails. > > > > > > > > > > > As a separate test, if the above test still fails, could you > > > > > > comment out the #define USE_BSNPRINTF 1 > > > > > > line in src/version.h and then rebuild everything? > > > > > > > > > > Yes it fails as well > > > > > > > > > > > Another interesting test would be to put: > > > > > > > > > > > > Dmsg1(000, "fmt=%s\n", fmt); > > > > > > > > > > > > just after the line "again:" at line 737 in src/dird/ua_output.c > > > > > > as well as: > > > > > > > > > > > > Dmsg0(000, "goto again\n"); > > > > > > > > > > > > after "msg = realloc_pool_memory(msg, maxlen + maxlen/2);" at > > > > > > line 741. Then report what it prints when the seg fault occurs. > > > > > > > > > > srvalum3-dir: ua_output.c:738 fmt=%s > > > > > srvalum3-dir: ua_output.c:738 fmt=%s > > > > > srvalum3-dir: ua_output.c:738 fmt=%s > > > > > srvalum3-dir: ua_output.c:738 fmt=%s > > > > > srvalum3-dir: ua_output.c:738 fmt=%s > > > > > srvalum3-dir: ua_output.c:743 goto again > > > > > srvalum3-dir: ua_output.c:738 fmt=%s > > > > > Kaboom! bacula-dir, srvalum3-dir got signal 11 - Segmentation > > > > > violation. Attempting traceback. > > > > > Kaboom! exepath=/usr/sbin/ > > > > > Calling: /usr/sbin/btraceback /usr/sbin/bacula-dir 16016 > > > > > Traceback complete, attempting cleanup ... > > > > > > > > > > And here is thread 2 > > > > > > > > > > Thread 2 (Thread 1098918208 (LWP 16043)): > > > > > #0 0x00002af703e5faef in waitpid () from /lib/libpthread.so.0 > > > > > #1 0x000000000046b9e3 in signal_handler (sig=11) at signal.c:167 > > > > > #2 <signal handler called> > > > > > #3 0x00002af704a06c10 in strlen () from /lib/libc.so.6 > > > > > #4 0x00002af7049d8b70 in vfprintf () from /lib/libc.so.6 > > > > > #5 0x00002af7049f9a4a in vsnprintf () from /lib/libc.so.6 > > > > > #6 0x0000000000452bac in bvsnprintf (str=0x9 <Address 0x9 out of > > > > > bounds>, size=<value optimized out>, > > > > > format=0x41801e01 "tn", ap=0x7) at bsys.c:292 > > > > > #7 0x0000000000431f6d in bmsg (ua=0x6e74a8, fmt=0x513af4 "%s", > > > > > arg_ptr=0x41801ec0) at ua_output.c:740 > > > > > #8 0x0000000000432326 in UAContext::send_msg (this=0x9, > > > > > fmt=0x513af4 "% s") at ua_output.c:778 > > > > > #9 0x000000000042e43c in sql_handler (ctx=0x6e74a8, num_field=3, > > > > > row=0x6e7738) at ua_dotcmds.c:480 > > > > > #10 0x00000000004508f2 in db_sql_query (mdb=0x6e7888, query=<value > > > > > optimized out>, result_handler=0x42e350 <sql_handler>, > > > > > ctx=0x6e74a8) at postgresql.c:320 > > > > > #11 0x000000000042dd57 in sql_cmd (ua=0x6e74a8, cmd=<value > > > > > optimized out>) at ua_dotcmds.c:496 > > > > > #12 0x000000000042da9b in do_a_dot_command (ua=0x6e74a8, > > > > > cmd=0x6f0f70 ".sql query=\"SELECT LogId, Time, LogText FROM Log > > > > > WHERE JobId='2674'\"") at ua_dotcmds.c:131 > > > > > #13 0x000000000043e75f in handle_UA_client_request (arg=<value > > > > > optimized out>) at ua_server.c:145 > > > > > #14 0x0000000000473c1d in workq_server (arg=<value optimized out>) > > > > > at workq.c:357 > > > > > #15 0x00002af703e58135 in start_thread () from /lib/libpthread.so.0 > > > > > #16 0x00002af704a5335e in clone () from /lib/libc.so.6 > > > > > #17 0x0000000000000000 in ?? () > > > > > > > > > > On this machine, gcc had three versions > > > > > > > > > > srvalum3 bacula # gcc-config -l > > > > > [1] x86_64-pc-linux-gnu-3.3.6 > > > > > [2] x86_64-pc-linux-gnu-4.1.1 * > > > > > [3] x86_64-pc-linux-gnu-4.1.2 > > > > > > > > > > So as an experiment I set gcc to 4.1.2 and recompiled bacula with > > > > > the same result. > > > > > > > > > > > > > > > Dirk > > > > > > > > > > > Best regards, > > > > > > > > > > > > Kern > > > > > > > > > > > > PS: for the list, the problem is clearly (according to the > > > > > > traceback) in Thread 2 between stack frame 4 and 5 where the > > > > > > argument "fmt" in stack frame 5 should be identical to argument > > > > > > "format" in stack frame 4, but has been shifted by 2 bytes! > > > > > > > > > > ------------------------------------------------------------------- > > > > >---- -- This SF.net email is sponsored by: Splunk Inc. > > > > > Still grepping through log files to find problems? Stop. > > > > > Now Search log events and configuration files using AJAX and a > > > > > browser. Download your FREE copy of Splunk now >> > > > > > http://get.splunk.com/ > > > > > _______________________________________________ > > > > > Bacula-devel mailing list > > > > > [email protected] > > > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > > > > > --------------------------------------------------------------------- > > > >---- This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a > > > > browser. Download your FREE copy of Splunk now >> > > > > http://get.splunk.com/ > > > > _______________________________________________ > > > > Bacula-devel mailing list > > > > [email protected] > > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > > > ----------------------------------------------------------------------- > > >-- This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > Bacula-devel mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
