On Tuesday 29 January 2008 01.23:03 Scott Barninger wrote: > OK, I'm a bit over my head here, but this seems like an issue for the > configure script, not packaging. Unless there is a simple env variable I > can set based upon a condition.
Well, the problem here is that someone or some process is setting _FORTIFY_SOURCE, and this is a bad thing to do. It should not be set and if building the rpm sets it automatically, someone will need to find a way to turn it off as I am not planning to change the source code, which is correct (maybe a bit unusual, but perfectly valid). Best regards, Kern > > On Tue, 2008-01-29 at 00:02 +0100, Michael Lausch wrote: > > The error is due to the new (well ~ core 5) buffer overflow checking > > implemented by gcc and glibc. _FORTIFY_SOURCE=2 activates it. what > > happens can be read in detail at > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html. but basically > > the error is a buffer overflow check in parse.c in the bacula library. > > > > In this file the following definition can be found: > > extern CURES res_all; > > CURES is a type defined in the library with a size of, let's say 120 > > bytes. the actual value is not important. > > > > In the bat module for example, the res_all variable is redefined as > > URES res_all; > > in bat_conf.cpp. URES is a type with, let's say, 250 bytes. The actual > > value is not important as long as it's larger then the size of the URES > > type defined in the library. The variable res_all_size is initialized to > > the size of the res_all variable, in my example to 250. > > > > In the init_resource() function in parse_conf.c is a call to > > memset(&res_all, 0, res_all_size); > > This call is replaced to a boundary checking memset() call as outlined > > by the example 2 in > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html > > The 3rd parameter of the memset call, res_all_size, which is 250, is > > checked against the size of the CURES type (120) and the buffer overflow > > error is raised by the boundary check of the memset function. > > > > > > The solution is to allocate the res_all variable dynamically. > > > > My quick hack solution was to change the definition of CURES to > > union CURES { > > MSGS res_msgs; > > RES hdr; > > char _space_[1024]; > > }; > > This makes the size of the CURES union larger than all the other unions > > defined in the different bacula executables and the memset check > > succeeds. But as i said this is a hack and i used it only as a band aid > > to get a runnable system. > > > > The solution to disable boundary checking by using a D_FORTIFY_SOURCE=0 > > definition in the compiler command line should not be done, because > > checking for errors in such a sensible application as a backup utility > > is always a good thing. > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ Bacula-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
