Jam segfault - Variable length > 1097

[kallisti5]

If a length of a variable is over 1097 characters, Jam will segfault.

Discovered when updating our u-boot script in ../build/jam/ArchitectureRules

This compiles as expected:

            # Modern u-boot fill in sane addresses for us.
            # Leverage the built-in fdt dtb for this board, unless a custom dtb is specified in uEnv.txt
            # uEnv.txt in qemu + virtio + u-boot causes a lockup for some reason.
            # qemu should be directly loading EFI however via edk2
            HAIKU_MMC_UBOOT_SCRIPT = "\
                echo \"Haiku u-boot script entry\" \
                test -e mmc 0 uEnv.txt && setenv media mmc \
                test -e virtio 0 uEnv.txt && setenv media virtio \
                test -e nvme 0 uEnv.txt && setenv media nvme \
                env exists media || echo \"ERROR: Unable to locate uEnv.txt on any known media!\" && exit \
                test -e ${media} 0 uEnv.txt && fatload ${media} 0 ${scriptaddr} uEnv.txt && env import -t ${scriptaddr} ${filesize} \
                env exists loader || echo \"ERROR: uEnv.txt doesn't specify bootloader!\" && exit \
                env exists platform || echo \"ERROR: uEnv.txt doesn't specify platform!\" && exit \
                echo \"uEnv.txt says to look for ${platform} bootloader named ${loader} on ${media} 0!\" \
                test -e ${media} 0 ${loader} && echo \"Found ${loader} on ${media} 0!\" \
                echo \"Loading bootloader...\" \
                fatload ${media} 0 ${kernel_addr_r} ${loader} \
                test -e ${media} 0 haiku_floppyboot.ub && fatload ${media} 0 ${ramdisk_addr_r} haiku_floppyboot.ub \
                echo \"Booting Haiku!\" \
                env exists dtb && echo \"Loading DTB...\" && fatload ${media} 0 ${fdt_addr_r} ${dtb} && fdt addr ${fdt_addr_r} \
                env exists dtb && echo \"Using internal DTB...\" && fdt addr ${fdtcontroladdr \
                hahahaha" ;

This will segfault:

            # Modern u-boot fill in sane addresses for us.
            # Leverage the built-in fdt dtb for this board, unless a custom dtb is specified in uEnv.txt
            # uEnv.txt in qemu + virtio + u-boot causes a lockup for some reason.
            # qemu should be directly loading EFI however via edk2
            HAIKU_MMC_UBOOT_SCRIPT = "\
                echo \"Haiku u-boot script entry\" \
                test -e mmc 0 uEnv.txt && setenv media mmc \
                test -e virtio 0 uEnv.txt && setenv media virtio \
                test -e nvme 0 uEnv.txt && setenv media nvme \
                env exists media || echo \"ERROR: Unable to locate uEnv.txt on any known media!\" && exit \
                test -e ${media} 0 uEnv.txt && fatload ${media} 0 ${scriptaddr} uEnv.txt && env import -t ${scriptaddr} ${filesize} \
                env exists loader || echo \"ERROR: uEnv.txt doesn't specify bootloader!\" && exit \
                env exists platform || echo \"ERROR: uEnv.txt doesn't specify platform!\" && exit \
                echo \"uEnv.txt says to look for ${platform} bootloader named ${loader} on ${media} 0!\" \
                test -e ${media} 0 ${loader} && echo \"Found ${loader} on ${media} 0!\" \
                echo \"Loading bootloader...\" \
                fatload ${media} 0 ${kernel_addr_r} ${loader} \
                test -e ${media} 0 haiku_floppyboot.ub && fatload ${media} 0 ${ramdisk_addr_r} haiku_floppyboot.ub \
                echo \"Booting Haiku!\" \
                env exists dtb && echo \"Loading DTB...\" && fatload ${media} 0 ${fdt_addr_r} ${dtb} && fdt addr ${fdt_addr_r} \
                env exists dtb && echo \"Using internal DTB...\" && fdt addr ${fdtcontroladdr \
                hahahahah" ;

(one extra 'h' character on end)

[kallisti5]

Pulkomandy pointed out Jam's MAXLINE length.

I've migrated these scripts into the tree via ​https://review.haiku-os.org/c/haiku/+/2963

So this one's a "known issue". It would be nice if Jam detected MAXLINE's over the limit and gave an error instead of quietly segfaulting however :-)