Dear Sirs,
I think I found a bug in gnu make program causing segmentation fault.
First I identified it in make version 3.79.1 on Linux 2.4.2-2smp
machine,
but next I tried the same version (3.79.1) on SunOS 5.7
Generic_106541-15 sun4u sparc machine
with the same result, then I verified that the previous versions
(3.75) are also affected
and the problem is platform independent.
Here is a makefile which causes make to segmentation fault:
--------------------
VPATH=./foodir/BarZxxq ./foodir/BarBar ./foodir/BarQuak
./foodir/BarPlumpZap ./foodir/BarMate ./foodir/BarHux ./foodir/BarCoq
./foodir/BarLaxse ./foodir/BarTus ./foodir/BarNv ./foodir/BarPatBun
./foodir/BarLarseNv ./foodir/BarCar ./bardir/Mlz ./bardir/Glust
./bardir/Rusta ./bardir/Kludx ./bardir/Foodle ./bardir/Kawer
./bardir/Ootx ./bardir/SweetHna ./bardir/PootYgQytrr
AR_LIB_NAME=foo
debug_lib_$(AR_LIB_NAME):
@echo "*****AR****RD01***********"
@echo "**debug for $@ ********"
@echo "***************************"
@echo " 0:VPATH=__ $(VPATH) __"
@echo " 1:$(@:debug_lib_%:%)_OBJ_LIST=__
$($(@:debug_lib_%:%)_OBJ_LIST) __"
--------------------
Of course the problem is related to ill formed macro substitution on
last line,
which normally should read
@echo " 1:$(@:debug_lib_%=%)_OBJ_LIST=__
$($(@:debug_lib_%=%)_OBJ_LIST) __"
But instead of being signaled as syntax error, this macro is expanded
and make crashes calling memmove with negative length.
here is gdb listing from make core dump on Solaris 2.7:
-------------------
#0 0xff1e0674 in memmove () from
/usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
#1 0x16294 in variable_expand_string (
line=0x69978 "\t@echo \" 1:rZxxq ./foodir/BarBar ./foodir/BarQuak
./foodir/BarPlumpZap ./foodir/BarMate ./foodir/BarHux ./foodir/BarCoq
./foodir/BarLaxse ./foodir/BarTus ./foodir/BarNv ./foodir/BarPatBun
./foodir/Bar",
string=0x67f58 "\t@echo \" 1:$(@:debug_lib_%:%)_OBJ_LIST=__
$($(@:debug_lib_%:%)_OBJ_LIST) __\"", length=-1)
at expand.c:337
#2 0x164ec in variable_expand (
line=0x67f58 "\t@echo \" 1:$(@:debug_lib_%:%)_OBJ_LIST=__
$($(@:debug_lib_%:%)_OBJ_LIST) __\"") at expand.c:415
#3 0x166ac in variable_expand_for_file (
line=0x67f58 "\t@echo \" 1:$(@:debug_lib_%:%)_OBJ_LIST=__
$($(@:debug_lib_%:%)_OBJ_LIST) __\"", file=0x63810)
at expand.c:465
#4 0x16900 in allocated_variable_expand_for_file (
line=0x67f58 "\t@echo \" 1:$(@:debug_lib_%:%)_OBJ_LIST=__
$($(@:debug_lib_%:%)_OBJ_LIST) __\"", file=0x63810)
at expand.c:535
#5 0x22b58 in new_job (file=0x63810) at job.c:1446
#6 0x13aa4 in execute_file_commands (file=0x63810) at commands.c:362
#7 0x35170 in remake_file (file=0x63810) at remake.c:1008
#8 0x33d94 in update_file_1 (file=0x63810, depth=0) at remake.c:659
#9 0x3241c in update_file (file=0x63810, depth=0) at remake.c:309
#10 0x31d08 in update_goal_chain (goals=0x69750, makefiles=0) at
remake.c:156
#11 0x26fb4 in main (argc=3, argv=0xffbef0fc, envp=0xffbef10c) at
main.c:1901
----------------
On Intel/Linux machine the stack is damaged and the calling routine
cannot be identified.
I understand that the described bug is a minor one, because no correct
Makefiles are affected.
But when the bug appears it's rather difficult to identify, so it would
be nice to have
some kind of warning suggesting that it is a problem with Makefile text
and not with gnu make program itself.
I believe that my description is accurate enough to reproduce
and identify the problem.
Yours Sincerely
Andrzej Wozniak
--
______________________________________________________________
_________| Andrzej Wozniak |_________
\ | Gene-IT, L'espace des Entrepreneurs, | /
\ | 5, rue du chant des oiseaux, | /
\ | 78360 MONTESSON, FRANCE | /
\ | Phone: +33 1 30 15 78 20 | /
/ | Fax: +33 1 30 15 78 77 | \
/ | Email : [EMAIL PROTECTED], http://www.gene-it.com | \
/ |_____________________________________________________________| \
/____________) (__________\
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make