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 ... > > 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
