Unallocated pointer freed in plpftp

[kapfab]

I was trying to recompile the latest changes on macOS and got an issue with plpftp when using the ls command:

malloc: *** error for object 0x195fc95d2: pointer being freed was not allocated

The issue comes from commit https://github.com/rrthomas/plptools/commit/5eb62f2745f12dfe790fe5e1bdc0fe372cc36512, adding line 934 to plpftp/ftp.cc:

        free(f1);

[rrthomas]

Thanks, that's what I meant by "0 tokens"! I'll look into it.

EDIT: Fixed, I hope. Also, I forgot to say that run/! has been specifically affected by this last commit, so needs special testing.

[kapfab]

I still get a segfault with empty prompts but run and ! work fine with 1 or 2 args.

EDIT: Using ! without arguments raises a shell error:

sh: -c: line 0: syntax error near unexpected token `newline'
sh: -c: line 0: `!'

It doesn’t make plpftp crash, but it would be nice to catch this specific case to show a syntax error instead of making sh angry… EDIT2: That might be a side effect of the latest changes because ! without args used to open an interactive shell.

I’ve also seen that filename completion ignore the drive prefix in the path, so completion for Z:\System\ lists the files in the System folder of the current drive. But that’s totally unrelated and probably never worked, that’ll be for another issue!

[rrthomas]

Thanks as ever, I'll work through this lot shortly.

I’ve also seen that filename completion ignore the drive prefix in the path, so completion for Z:\System\ lists the files in the System folder of the current drive. But that’s totally unrelated and probably never worked, that’ll be for another issue!

Yes indeed, please file fresh issues for anything else. (In the end, doesn't much matter whether it's an old or new bug!)

[kapfab]

Regarding the segfault, it's not due to the very last change but to a previous one (https://github.com/rrthomas/plptools/commit/fd075a11a4302551ce9deba8527fef0bc384d51b). In getCommand, checking buf seems to fix the issue and reinstate the previous behaviour (looping until a command is actually entered):

    while (continueRunning) {
        signal(SIGINT, sigint_handler2);
        free(buf);
        buf = readline("> ");
        if (!buf)
            cout << "bye" << endl;
        else {
            if (strlen(buf)) {
                add_history(buf);
                break;
            }
        }
        signal(SIGINT, sigint_handler);
    }

[rrthomas]

Regarding the segfault, it's not due to the very last change but to a previous one (fd075a1). In getCommand, checking buf seems to fix the issue and reinstate the previous behaviour (looping until a command is actually entered):

I've fixed this now, thanks. Are we left with "just" the misbehaviour of ! with no arguments?

[kapfab]

Sorry, I completely forgot to test the latest changes… I directly get a SEGFAULT as soon as plpftp asks for a command. It works fine in non-interactive mode (i.e. plpftp ls or plpftp ?).

[rrthomas]

Edit: what I just said was nonsense; what I need for proper testing (and don't have) is an EPOC device, not a Mac!

[kapfab]

Changing while (!strlen(buf) && continueRunning) to while (continueRunning) seems enough to fix it.

[rrthomas]

I think it should be while ((!buf || !strlen(buf)) && continueRunning) { so that the loop continues until we have some input.

[rrthomas]

I have updated the most recent commit to add this extra check, thanks!

[kapfab]

buf should not be tested to enter this loop as it's never null here once a first command has been entered. If the readline loop is skipped, buf keeps its previous value, leading to getCommand being called endlessly (with the same return value).

I also get a SEGFAULT when entering only spaces (one or more) as a command, but I think this has probably always been like that.

[rrthomas]

buf should not be tested to enter this loop as it's never null here once a first command has been entered.

That's not a problem: the test is redundant but not harmful.

However, there are other problems. I've simplified getCommand, removing the loop, and instead coping with empty input in the caller.

I also get a SEGFAULT when entering only spaces (one or more) as a command, but I think this has probably always been like that.

Hopefully also fixed now.

[kapfab]

Cannot test it right now but the code looks much cleaner like that, with a single loop!

[rrthomas]

(I had a look at stubbing out the code that talks to the EPOC device in order to be able to test the ftp parser without one, but it's not easy—I think it would be more straightforward to add mock-device code for ncpd so that it could pretend to be a real device without having one plugged in.)

[kapfab]

I wish MAME or WindEmu could emulate the Series 5 serial comms!

[kapfab]

Series 3 emulator in DOSBox seems to handle serial comms, that might be a way to test a part of ncpd and plpftp.

EDIT: A very recent fix in MAME should also make it possible to emulate PLP with a Psion Series 3.