Segmentation fault

[Kristoffer Koch]

Hi tup-users!

I'm currently exploring tup for building a large-ish embedded system, and it seems very good. However, I'm currently experiencing a segfault:

Thread 4 "tup" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff603d700 (LWP 19864)]
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:427
427    ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:427
#1  0x000055555557953a in estring_append (e=0x7ffff603b3e0, src=0x1 <error: Cannot access memory at address 0x1>, len=-1) at estring.c:53
#2  0x000055555558d12f in tup_printf (tf=0x7ffff603bc60, cmd=0x7fffe8021514 "$(CC_LOS_%e) $(CFLAGS_LOS_%e) -c %f -o %o", cmd_len=41, nl=0x7ffff603b650, onl=0x7ffff603b530,
    ooinput_nl=0x7ffff603b868, ext=0x1 <error: Cannot access memory at address 0x1>, extlen=-1, extra_command=0x0) at parser.c:3616
#3  0x000055555558ba2c in do_rule (tf=0x7ffff603bc60, r=0x7ffff603b7f0, nl=0x7ffff603b650, ext=0x1 <error: Cannot access memory at address 0x1>, extlen=-1,
    output_nl=0x7ffff603b7a0) at parser.c:3235
#4  0x0000555555588172 in execute_rule (tf=0x7ffff603bc60, r=0x7ffff603b7f0, output_nl=0x7ffff603b7a0) at parser.c:1967
#5  0x0000555555586739 in parse_rule (tf=0x7ffff603bc60, p=0x7fffe8023417 " foreach $(SOURCE_FILES_LOS)", lno=32, bl=0x7ffff603b990) at parser.c:1348
#6  0x00005555555846b2 in parse_tupfile (tf=0x7ffff603bc60, b=0x7ffff603bac0, filename=0x7fffe801ea20 "../../build/myriad2.tup") at parser.c:646
#7  0x00005555555861fa in parser_include_file (tf=0x7ffff603bc60, file=0x7fffe801ea20 "../../build/myriad2.tup") at parser.c:1242
#8  0x000055555558451c in parse_tupfile (tf=0x7ffff603bc60, b=0x7ffff603bc40, filename=0x5555556866a5 "Tupfile") at parser.c:632
#9  0x0000555555583167 in parse (n=0x555556405fc0, g=0x7fffffffe160, retts=0x0, refactoring=0, use_server=1) at parser.c:286
#10 0x000055555559950b in create_work (g=0x7fffffffe160, n=0x555556405fc0) at updater.c:1820
#11 0x0000555555599460 in run_thread (arg=0x5555564a3c40) at updater.c:1806
#12 0x00007ffff762b7fc in start_thread (arg=0x7ffff603d700) at pthread_create.c:465
#13 0x00007ffff7358b5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

I can't share the project, and it doesn't seem trivial to create a test-case, but I would very much like to help solve this :)

Best regards, Kristoffer

[Mike Shal]

Hi Kristoffer,

Thanks for the detailed backtrace! I think the problem is when using
%e when some of the files have no extension. I've added t6075 to check
for this and pushed what should be a fix. Can you pull the latest
master and see if it helps?

Note that the current expected behavior when using %e with a file
without an extension is to fail with an error message, so your setup
will probably still fail (though ideally without the segfault this
time). We could probably define different semantics if you think
there's a compelling use-case for it.

-Mike

[Kristoffer Koch]

I don't think I have extension-less files, but it seems like the code (very advanced debugging here..) doesn't like extlen < 0.

The following patch stopped the segfault, and let me carry on with business :)

--- a/src/tup/parser.c
+++ b/src/tup/parser.c
@@ -1964,7 +1964,7 @@ int execute_rule(struct tupfile *tf, struct rule *r, struct name_list *output_nl
                        /* The extension in do_rule() does not include the
                         * leading '.'
                         */
-                       if(do_rule(tf, r, &tmp_nl, ext+1, extlen-1, output_nl) < 0)
+                       if(extlen > 0 && do_rule(tf, r, &tmp_nl, ext+1, extlen-1, output_nl) < 0)
                                return -1;
 
                        if(is_bang) {

Also, poking around, if I turned on `-fsanitize=undefined`, I get some complaints that strcmp gets called with NULL pointers (also with 0 length, but evidently, no NULL is allowed). For debug builds, I really like the whole paranoid `-fsanitize` family, in addition to `-fstack-protector=all`.

I haven't looked around much, but tup is so far really nice to work with! Thanks a lot.

-Kristoffer
 

[Mike Shal]

On Mon, Feb 19, 2018 at 2:41 AM, Kristoffer Koch <krist...@huddly.com> wrote:
> Also, poking around, if I turned on `-fsanitize=undefined`, I get some
> complaints that strcmp gets called with NULL pointers (also with 0 length,
> but evidently, no NULL is allowed). For debug builds, I really like the
> whole paranoid `-fsanitize` family, in addition to `-fstack-protector=all`.

Thanks for the heads up! I've fixed the issues with -fsanitize=address
and -fsanitize=undefined, and added a build for that in my CI setup to
prevent them from coming back.

-Mike