Hi Kristoffer, On Sun, Feb 18, 2018 at 4:08 AM, Kristoffer Koch <[email protected]> wrote: > 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 :)
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 -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
