"stack smashing detected" when make check of glibc
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"stack smashing detected" when make check of glibc
Hello there,
I followed instructions in LFS 11.3 and everything worked until
"stack smashing detected" reported when doing make check in 8.5.
I tried a second time after rming & restoring backup made in 7.13 and failed with the same error.
I can't figure out the root cause and guess it has something to do with glibc, since ls/ldd also errored( but don't know why pwd didn't).
The libc etc on partly build lfs:
Code:
root@slacktest:~# ls $LFS/usr/lib/libc* -l
-rw-r--r-- 1 root root 24545770 Aug 28 07:47 /mnt/lfs/usr/lib/libc.a
-rw-r--r-- 1 root root 255 Aug 23 10:05 /mnt/lfs/usr/lib/libc.so
-rwxr-xr-x 1 root root 12430032 Aug 28 07:47 /mnt/lfs/usr/lib/libc.so.6
lrwxrwxrwx 1 root root 22 Aug 23 10:05 /mnt/lfs/usr/lib/libc_malloc_debug.so -> libc_malloc_debug.so.0
-rwxr-xr-x 1 root root 191648 Aug 23 10:05 /mnt/lfs/usr/lib/libc_malloc_debug.so.0
-rw-r--r-- 1 root root 22242 Aug 28 07:47 /mnt/lfs/usr/lib/libc_nonshared.a
-rw-r--r-- 1 root root 159452 Aug 23 10:05 /mnt/lfs/usr/lib/libcrypt.a
lrwxrwxrwx 1 root root 13 Aug 23 10:05 /mnt/lfs/usr/lib/libcrypt.so -> libcrypt.so.1
-rwxr-xr-x 1 root root 132032 Aug 23 10:05 /mnt/lfs/usr/lib/libcrypt.so.1
lrwxrwxrwx 1 root root 21 Aug 23 15:10 /mnt/lfs/usr/lib/libctf-nobfd.so -> libctf-nobfd.so.0.0.0
lrwxrwxrwx 1 root root 21 Aug 23 15:10 /mnt/lfs/usr/lib/libctf-nobfd.so.0 -> libctf-nobfd.so.0.0.0
-rwxr-xr-x 1 root root 1514768 Aug 23 15:10 /mnt/lfs/usr/lib/libctf-nobfd.so.0.0.0
lrwxrwxrwx 1 root root 15 Aug 23 15:10 /mnt/lfs/usr/lib/libctf.so -> libctf.so.0.0.0
lrwxrwxrwx 1 root root 15 Aug 23 15:10 /mnt/lfs/usr/lib/libctf.so.0 -> libctf.so.0.0.0
-rwxr-xr-x 1 root root 1351520 Aug 23 15:10 /mnt/lfs/usr/lib/libctf.so.0.0.0
root@slacktest:~#
I searched but had no clue as to what to do with it, hope someone here could possbilily point me in the right direction.
**********
Correction: "make test" in both title and the post should be "make install", I just recall it a moment ago and sorry for the confusion.
**********
Last edited by braving; 08-29-2023 at 01:31 AM.
Reason: make check should be make install & sorry for the confusion
Stacks are ram spaces internal to the cpu. Let's stick with 1 process, 1 core, & no OS just for the purposes of explaining. There are 2 stack assembler instructions
push <register>
pop <register>
Now if your process was running and received an interrupt, it would want to deal with that, so it might need a few registers. So it could issue short 'push' instructions to registers to save their contents, handle the interrupt, and then issue pop instructions IN REVERSE ORDER to the same registers to restore their contents. The security risk is that you can put numbers on the stack, knowing that sooner or later they will be popped into a register and acted on. There's no builtin error checking.
With multicore cpus running hundreds of processes and an OS jumping in, it's vastly more complicated. Stack protection is implemented, and your own kernel probably has raised a red flag, and killed the compile. That's what it looks like.
Start over. New archive, new compile, check the checksum on the download, reapply the patches (if any) and see if it happens the second time. What's your host OS? Some are not suitable.
root@slacktest14:~# uname -a
Linux slacktest14 3.2.29 #2 SMP Mon Sep 17 14:19:22 CDT 2012 x86_64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz GenuineIntel GNU/Linux
root@slacktest14:~#
I remembered an off-track which I recalled & forgot again while reading your answer: gcc being 4.9, not 5.1 as in host requirment. I will start over again as you suggested with correct gcc and may be other libs version.
While looking for clues, I found there is livecd version of lfs and can service as a known good host to build things and therefore may act as plan B for me I think.
Anyway I will get back. Enjoy the day!
Gcc-5.x is seriously old. If you're building antique software, you know what you're doing. Older stuff often has exploitable holes.
My slackware64-15.0 has gcc-11.2.0, glibc-2.33 & LTS kernel 5.15.63( originally 5.15.19). I installed ~Current on my Raspberry Pi last night. That has gcc-13.2.0, glibc-2.37 & kernel-6.4.8. I'd use a modern system to install modern stuff with. You're running kernel-3.2.29, & gcc-4.9. Be serious. That's your problem!
You're also going to run into countless 'undefined reference' errors and bizarre errors from ancient headers. In short, install a much newer system before you compile anything.
Hi business_kid,
Thanks for the input, I'd say my system is much old and I'm considering an upgrade and in fact this building lfs is part of the effort and till now it has not been much progress.
The 5.1 gcc and 3.2 kernel is as what required in LFS book 11.3, which is the highest version I had read about, the livecd thing is much older so I'd stick with 11.3 and see where it goes.
Have a good day.
=============
There actually is LFS 12.0 with much higher os &libs, but since 11.3 is what I have system most close to and all the packages, I may just don't switch, and besides it is just one version higher.
Errors occured during make in 5.3 (GCC12.2.0 pass 1)
Code:
g++ -std=gnu++11 -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I/mnt/lfs/sources/gcc-12.2.0/build/./gmp -I/mnt/lfs/sources/gcc-12.2.0/gmp -I/mnt/lfs/sources/gcc-12.2.0/build/./mpfr/src -I/mnt/lfs/sources/gcc-12.2.0/mpfr/src -I/mnt/lfs/sources/gcc-12.2.0/mpc/src -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o i386.o -MT i386.o -MMD -MP -MF ./.deps/i386.TPo ../../gcc/config/i386/i386.cc
In file included from ../../gcc/config/i386/i386.cc:95:0:
../../gcc/config/i386/i386-builtins.h:310:1: error: narrowing conversion of '9223372036854775808ul' from 'long unsigned int' to 'long int' inside { }
};
^
../../gcc/config/i386/i386-builtin.def:472:1: note: in expansion of macro 'BDESC_END'
BDESC_END (SPECIAL_ARGS, PURE_ARGS)
^
../../gcc/config/i386/i386-builtins.h:310:1: error: narrowing conversion of '9223372036854775808ul' from 'long unsigned int' to 'long int' inside { }
};
^
../../gcc/config/i386/i386-builtin.def:472:1: note: in expansion of macro 'BDESC_END'
BDESC_END (SPECIAL_ARGS, PURE_ARGS)
^
../../gcc/config/i386/i386-builtins.h:310:1: error: narrowing conversion of '9223372036854775810ul' from 'long unsigned int' to 'long int' inside { }
};
^
../../gcc/config/i386/i386-builtin.def:472:1: note: in expansion of macro 'BDESC_END'
BDESC_END (SPECIAL_ARGS, PURE_ARGS)
^
../../gcc/config/i386/i386-builtins.h:310:1: error: narrowing conversion of '9223372036854775810ul' from 'long unsigned int' to 'long int' inside { }
};
^
../../gcc/config/i386/i386-builtin.def:472:1: note: in expansion of macro 'BDESC_END'
BDESC_END (SPECIAL_ARGS, PURE_ARGS)
^
../../gcc/config/i386/i386.cc:203:1: error: narrowing conversion of '4294967294u' from 'unsigned int' to 'int' inside { }
};
^
../../gcc/config/i386/i386.cc:203:1: error: narrowing conversion of '4294967294u' from 'unsigned int' to 'int' inside { }
../../gcc/config/i386/i386.cc:203:1: error: narrowing conversion of '4294967294u' from 'unsigned int' to 'int' inside { }
../../gcc/config/i386/i386.cc:203:1: error: narrowing conversion of '4294967294u' from 'unsigned int' to 'int' inside { }
../../gcc/config/i386/i386.cc:203:1: error: narrowing conversion of '4294967295u' from 'unsigned int' to 'int' inside { }
../../gcc/config/i386/i386.cc:203:1: error: narrowing conversion of '4294967295u' from 'unsigned int' to 'int' inside { }
and dozens of almost identical lines as the last follow.
Then make abort:
Code:
../../gcc/config/i386/i386.cc:313:1: error: narrowing conversion of '4294967295u' from 'unsigned int' to 'int' inside { }
../../gcc/config/i386/i386.cc:313:1: error: narrowing conversion of '4294967295u' from 'unsigned int' to 'int' inside { }
Makefile:2414: recipe for target 'i386.o' failed
make[2]: *** [i386.o] Error 1
make[2]: Leaving directory '/mnt/lfs/sources/gcc-12.2.0/build/gcc'
Makefile:4601: recipe for target 'all-gcc' failed
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory '/mnt/lfs/sources/gcc-12.2.0/build'
Makefile:1017: recipe for target 'all' failed
make: *** [all] Error 2
lfs:/mnt/lfs/sources/gcc-12.2.0/build$
Some warnings before the above errors:
Code:
g++ -std=gnu++11 -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I/mnt/lfs/sources/gcc-12.2.0/build/./gmp -I/mnt/lfs/sources/gcc-12.2.0/gmp -I/mnt/lfs/sources/gcc-12.2.0/build/./mpfr/src -I/mnt/lfs/sources/gcc-12.2.0/mpfr/src -I/mnt/lfs/sources/gcc-12.2.0/mpc/src -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o tree-diagnostic-path.o -MT tree-diagnostic-path.o -MMD -MP -MF ./.deps/tree-diagnostic-path.TPo ../../gcc/tree-diagnostic-path.cc
../../gcc/tree-diagnostic-path.cc: In member function 'virtual label_text {anonymous}::path_label::get_text(unsigned int) const':
../../gcc/tree-diagnostic-path.cc:68:60: warning: unknown conversion type character '@' in format [-Wformat=]
pp_printf (&pp, "%@ %s", &event_id, event_text.m_buffer);
^
../../gcc/tree-diagnostic-path.cc:68:60: warning: format '%s' expects argument of type 'char*', but argument 3 has type 'diagnostic_event_id_t*' [-Wformat=]
../../gcc/tree-diagnostic-path.cc:68:60: warning: too many arguments for format [-Wformat-extra-args]
../../gcc/tree-diagnostic-path.cc: In member function 'void {anonymous}::event_range::print(diagnostic_context*)':
more warnings:
Code:
g++ -std=gnu++11 -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libcody -I/mnt/lfs/sources/gcc-12.2.0/build/./gmp -I/mnt/lfs/sources/gcc-12.2.0/gmp -I/mnt/lfs/sources/gcc-12.2.0/build/./mpfr/src -I/mnt/lfs/sources/gcc-12.2.0/mpfr/src -I/mnt/lfs/sources/gcc-12.2.0/mpc/src -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -o tree-vect-data-refs.o -MT tree-vect-data-refs.o -MMD -MP -MF ./.deps/tree-vect-data-refs.TPo ../../gcc/tree-vect-data-refs.cc
In file included from ../../gcc/hash-table.h:248:0,
from ../../gcc/coretypes.h:486,
from ../../gcc/tree-vect-data-refs.cc:24:
../../gcc/vec.h: In function 'void vect_permute_load_chain(vec_info*, vec<tree_node*>, unsigned int, stmt_vec_info, gimple_stmt_iterator*, vec<tree_node*>*)':
../../gcc/vec.h:890:19: warning: array subscript is above array bounds [-Warray-bounds]
return m_vecdata[ix];
^
../../gcc/vec.h:890:19: warning: array subscript is above array bounds [-Warray-bounds]
../../gcc/vec.h: In function 'bool vect_grouped_store_supported(tree, long unsigned int)':
../../gcc/vec.h:890:19: warning: array subscript is above array bounds [-Warray-bounds]
return m_vecdata[ix];
The packages are md5 checked and have the correct versions:
Code:
lfs:~$ bash version-check.sh
bash, version 4.2.37(2)-release
/bin/sh -> /bin/bash
Binutils: (Linux/GNU Binutils) 2.22.52.0.2.20120424
bison (GNU Bison) 2.7
yacc is bison (GNU Bison) 2.7
Coreutils: 8.19
diff (GNU diffutils) 3.2
find (GNU findutils) 4.4.2
GNU Awk 3.1.8
/usr/bin/awk -> /bin/gawk-3.1.8
gcc (GCC) 5.1.0
g++ (GCC) 5.1.0
grep (GNU grep) 2.14
gzip 1.5
Linux version 3.2.29 (root@hive64) (gcc version 4.7.1 (GCC) ) #2 SMP Mon Sep 17 14:19:22 CDT 2012
m4 (GNU M4) 1.4.16
GNU Make 4.0
GNU patch 2.7
Perl version='5.16.1';
Python 3.4.0
GNU sed version 4.2.1
tar (GNU tar) 1.26
makeinfo (GNU texinfo) 4.13
xz (XZ Utils) 5.0.4
g++ compilation OK
lfs:~$
The 5.1 gcc and 3.2 kernel is as what required in LFS book 11.3, which is the highest version I had read about, the livecd thing is much older so I'd stick with 11.3 and see where it goes.
Have a good day.
=============
There actually is LFS 12.0 with much higher os &libs, but since 11.3 is what I have system most close to and all the packages, I may just don't switch, and besides it is just one version higher.
I don't know where you are getting your info from. I've just called up the current stable LFS (which is indeed 11.3) and it has gcc-12.2.0 and kernel 6.1.11.
I don't know where you are getting your info from. I've just called up the current stable LFS (which is indeed 11.3) and it has gcc-12.2.0 and kernel 6.1.11.
Thank you hazel for the input, u r right in the highest stable version being 11.3 with GCC12 and kernel 6 being the verions of target. I just found LFS 12 is rc version.
GCC5.1 and 3.2 kernel https://www.linuxfromscratch.org/lfs.../hostreqs.htmlis the minimum requirement of the host, and I think things should go well if that are met.
Update follow #6
After upgrade gcc from 5.1 to 5.2 on host and start all over again, it worked until errored in 8.5 make install, with seemingly the same error as #1 "stack smashing detected":
BTW, building on lfs livecd 6.3 worked, but no reference seemed can be drawn here since the build process is quite subtle and different.
Any suggestion is greatly welcome.
Just a note in passing. Gcc-5.1.x and kernel-3.x are very old by modern standards. Glibc-2.37 and gcc-12.2.x are quite new. It's best for LFS to have programs of the same vintage compiling together. You apparently have a fairly old system doing the work. Is that a Red Hat system? RH, Centos, Fedora, Scientific Linux, etc.
None of those make good bases for LFS. I tried. The second pass of gcc in chapter 6 has tests that fairly well have to pass. They didn't, and I went down in flames. I had to throw that work away. It's better to save you pain now if you're on that road.
By the time you get to chapter 8, you should be using your own tools exclusively. That includes the final version of gcc-13.2.0 built in chapter 6.18. So now I'm as puzzled as you are.
LFS doesn't support the live cd any more and no later versions have been produced. I'm surprised that an old one still worked for you. But you need to understand that the build process of the latest versions is completely different logically from the older method in which all the tools were built in the tools directory. Nowadays most of the toolchain is installed directly onto the new partition and then overwritten by the final versions.
By the time you get to chapter 8, you should be using your own tools exclusively. That includes the final version of gcc-13.2.0 built in chapter 6.18. So now I'm as puzzled as you are.
LFS doesn't support the live cd any more and no later versions have been produced. I'm surprised that an old one still worked for you. But you need to understand that the build process of the latest versions is completely different logically from the older method in which all the tools were built in the tools directory. Nowadays most of the toolchain is installed directly onto the new partition and then overwritten by the final versions.
He could build LFS from one of Alien Bob's LiveSlak usb keys, couldn't he? That would look after the versions problem. I imagine some have done it already. Any linux that will runs a bash script and has Squashfs tools should build the Liveslak usb.
Just a note in passing. Gcc-5.1.x and kernel-3.x are very old by modern standards. Glibc-2.37 and gcc-12.2.x are quite new. It's best for LFS to have programs of the same vintage compiling together. You apparently have a fairly old system doing the work. Is that a Red Hat system? RH, Centos, Fedora, Scientific Linux, etc.
None of those make good bases for LFS. I tried. The second pass of gcc in chapter 6 has tests that fairly well have to pass. They didn't, and I went down in flames. I had to throw that work away. It's better to save you pain now if you're on that road.
Hi Business_kid,
Yes, Gcc 5.1 and kernel 3.2 are fairly old but they are on the sw/os version list supported by lfs 11.3 so I take that it should work with these versions though the progress so far didn't.
I have projects at workplace that use gcc 4.9, glibc 2.17(19?), Qt5.x etc , so I need to upgrade to a system with these old versions of apps that is why I can't just go straight to "modern" systems.
By the time you get to chapter 8, you should be using your own tools exclusively. That includes the final version of gcc-13.2.0 built in chapter 6.18. So now I'm as puzzled as you are.
LFS doesn't support the live cd any more and no later versions have been produced. I'm surprised that an old one still worked for you. But you need to understand that the build process of the latest versions is completely different logically from the older method in which all the tools were built in the tools directory. Nowadays most of the toolchain is installed directly onto the new partition and then overwritten by the final versions.
Hi hazel,
Yes, I followed the build process as the book said but since there are many steps I'm not sure if there isn't any mistake made, or if its just version vintage problem as Business_kid said.
I just recalled that right before 8.5 make install, make test finished with errors plus dozons of fail, xfail and xpass(no idea what the later two are for). Don't know if that matters.
I just recalled that right before 8.5 make install, make test finished with errors plus dozons of fail, xfail and xpass(no idea what the later two are for). Don't know if that matters.
Yes, it does. The XFAIL and XPASS (expected failure and unexpected success) are not significant. Expected failures are due to your system, not the software under test, and unexpected passes are just freaks. But if you get a lot of real failures on something as vital as glibc, that indicates a serious problem. The first thing to do is to go to the test website (link given in the gcc build chapter) and see if the official build gave those failures too.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
