• Htick Hatching

    From Paul Hayton@3:770/100 to All on Thu Mar 11 16:38:27 2021
    HI there

    I've been hatching some files out using Htick

    It seems to run and toss a file to nodes fileboxes and also the tics... but
    at the end of the run I see this

    7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic 1byzrpvz.tic for 21:1/213 via 21:1/213
    double free or corruption (fasttop)
    Aborted


    Any ideas what this might be?

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Michael Dukelsky@2:5020/1042 to Paul Hayton on Thu Mar 11 11:11:08 2021
    Hello Paul,

    Thursday March 11 2021, Paul Hayton wrote to All:

    I've been hatching some files out using Htick

    It seems to run and toss a file to nodes fileboxes and also the
    tics... but at the end of the run I see this

    7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic 1byzrpvz.tic
    for
    21:1/213 via 21:1/213

    I did not find such a diagnostics in the Husky code:

    double free or corruption (fasttop)
    Aborted

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From andrew clarke@3:633/267 to Michael Dukelsky on Thu Mar 11 21:47:28 2021
    On 2021-03-11 11:11:08, Michael Dukelsky (2:5020/1042) wrote to Paul Hayton:

    I've been hatching some files out using Htick

    It seems to run and toss a file to nodes fileboxes and also the
    tics... but at the end of the run I see this

    7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic
    1byzrpvz.tic for
    21:1/213 via 21:1/213

    I did not find such a diagnostics in the Husky code:

    double free or corruption (fasttop)
    Aborted

    This is likely due to free() being called twice on the same pointer somewhere in the Linux build of HTick.

    In C this is undefined behaviour, though most operating systems won't flag it as a bug.

    $ cat free-twice.c
    #include <stdlib.h>

    int main(void)
    {
    char *p;
    p = malloc(42);
    free(p);
    free(p);
    return 0;
    }

    $ make free-twice
    cc free-twice.c -o free-twice

    $ ./free-twice
    free(): double free detected in tcache 2
    zsh: abort ./free-twice

    The exact error message probably differs depending on what kernel options are set.

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description: Ubuntu 20.04.2 LTS
    Release: 20.04
    Codename: focal

    --- GoldED+/BSD 1.1.5-b20180707
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
  • From Michael Dukelsky@2:5020/1042 to andrew clarke on Thu Mar 11 13:54:56 2021
    Hello andrew,

    Thursday March 11 2021, andrew clarke wrote to Michael Dukelsky:

    double free or corruption (fasttop)
    Aborted

    This is likely due to free() being called twice on the same pointer somewhere in the Linux build of HTick.

    OK, thank you. It should be easy to fix.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michael Dukelsky@2:5020/1042 to Paul Hayton on Thu Mar 11 19:04:08 2021
    Hello Paul,

    Thursday March 11 2021, Paul Hayton wrote to All:

    I've been hatching some files out using Htick

    It seems to run and toss a file to nodes fileboxes and also the
    tics... but at the end of the run I see this

    7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic 1byzrpvz.tic
    for
    21:1/213 via 21:1/213
    double free or corruption (fasttop)
    Aborted

    Hopefully, I fixed it. Please pull and rebuild everything.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Paul Hayton@3:770/100 to Michael Dukelsky on Fri Mar 12 13:45:58 2021
    On 11 Mar 2021 at 07:04p, Michael Dukelsky pondered and said...

    Hopefully, I fixed it. Please pull and rebuild everything.

    Michael

    Many thanks.

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From andrew clarke@3:633/267 to Michael Dukelsky on Fri Mar 12 22:07:02 2021
    On 2021-03-11 13:54:56, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

    double free or corruption (fasttop)
    Aborted

    This is likely due to free() being called twice on the same pointer
    somewhere in the Linux build of HTick.

    OK, thank you. It should be easy to fix.

    nfree() may help but it's not foolproof. Consider this:

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    static void foo(char *p)
    {
    printf("%s\n", p);
    nfree(p);
    }

    int main(void)
    {
    char *p = malloc(42);
    strcpy(p, "Hello!");
    foo(p);
    nfree(p);
    return 0;
    }

    Here foo() can only set its local copy of p to NULL. It can't modify the original pointer.

    There's not really any way around this kind of mistake in C, other than to run it through a debugger, examine the code and fix it by hand.

    --- GoldED+/BSD 1.1.5-b20180707
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
  • From Wilfred van Velzen@2:280/464 to andrew clarke on Fri Mar 12 12:40:28 2021
    Hi andrew,

    On 2021-03-12 22:07:02, you wrote to Michael Dukelsky:

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    And the test for NULL isn't necessary, because free() is by definition doing nothing if the pointer passed to it is NULL.

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michael Dukelsky@2:5020/1042 to andrew clarke on Fri Mar 12 15:29:34 2021
    Hello andrew,

    Friday March 12 2021, andrew clarke wrote to Michael Dukelsky:

    double free or corruption (fasttop)
    Aborted

    This is likely due to free() being called twice on the same
    pointer somewhere in the Linux build of HTick.

    OK, thank you. It should be easy to fix.

    nfree() may help but it's not foolproof. Consider this:

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    static void foo(char *p)
    {
    printf("%s\n", p);
    nfree(p);
    }

    int main(void)
    {
    char *p = malloc(42);
    strcpy(p, "Hello!");
    foo(p);
    nfree(p);
    return 0;
    }

    Here foo() can only set its local copy of p to NULL. It can't modify
    the original pointer.

    There's not really any way around this kind of mistake in C, other
    than to run it through a debugger, examine the code and fix it by
    hand.

    We'll wait for Paul to test it.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Fri Mar 12 15:30:48 2021
    Hello Wilfred,

    Friday March 12 2021, Wilfred van Velzen wrote to andrew clarke:

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    And the test for NULL isn't necessary, because free() is by definition doing nothing if the pointer passed to it is NULL.

    Yes, I know it. It was written long ago and not by me and I do not change it because I do not know whether free() always worked as it works now or it did not test the pointer for NULL in some ancient systems.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Wilfred van Velzen@2:280/464 to Michael Dukelsky on Fri Mar 12 13:52:18 2021
    Hi Michael,

    On 2021-03-12 15:30:48, you wrote to me:

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    And the test for NULL isn't necessary, because free() is by definition
    doing nothing if the pointer passed to it is NULL.

    Yes, I know it. It was written long ago and not by me and I do not change it because I do not know whether free() always worked as it works now or it
    did not test the pointer for NULL in some ancient systems.

    The Second Edition (1988) of The C Programming Language by Kernighan & Ritchie (describes C as defined by the ANSI standard), already describes it as follows:

    void free(void *p)
    free deallocates the space pointed to by p; it does nothing if p is NULL. p must be a pointer to space previously allocated by calloc, malloc, or realloc.

    So I think you are save to assume it "always" worked that way! ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Fri Mar 12 16:54:06 2021
    Hello Wilfred,

    Friday March 12 2021, Wilfred van Velzen wrote to Michael Dukelsky:

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    And the test for NULL isn't necessary, because free() is by
    definition doing nothing if the pointer passed to it is NULL.

    Yes, I know it. It was written long ago and not by me and I do
    not change it because I do not know whether free() always worked
    as it works now or it did not test the pointer for NULL in some
    ancient systems.

    The Second Edition (1988) of The C Programming Language by Kernighan & Ritchie (describes C as defined by the ANSI standard), already
    describes it as follows:

    void free(void *p)
    free deallocates the space pointed to by p; it does nothing if p is NULL. p must be a pointer to space previously allocated by calloc,
    malloc, or realloc.

    So I think you are save to assume it "always" worked that way! ;)

    OK, thanks.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Paul Hayton@3:770/100 to Michael Dukelsky on Sat Mar 13 16:23:12 2021
    On 11 Mar 2021 at 07:04p, Michael Dukelsky pondered and said...

    7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic 1byzrpvz.tic for
    21:1/213 via 21:1/213
    double free or corruption (fasttop)
    Aborted

    Hopefully, I fixed it. Please pull and rebuild everything.

    OK I am new to Linux but I went into my source files for the following directories and did a 'git pull' for each

    hpt
    htick
    huskylib
    fidoconf
    areafix
    huskybse
    smapi
    hptzip

    I then ran 'make' and 'make install' in this order

    huskylib
    smapi
    fidoconf
    areafix
    hptzip
    hpt
    htick

    Testing htick I see the same error

    7 Mar:13:2021:16:07:14 Forwarding
    blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66y.tic for 21:1/212 via 21:1/212
    7 Mar:13:2021:16:07:14 Forwarding
    blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66z.tic for 21:1/213 via 21:1/213
    double free or corruption (fasttop)
    Aborted


    But I did have a thought.... should I have copied the new huskymak.xx and edited it and placed that in the root huksy directory before I complied the
    new versions?

    I am now running versions

    htick/lnx 1.9.0-cur 2021-03-11
    hpt/lnx 1.9.0-cur 2021-03-11

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Michael Dukelsky@2:5020/1042 to Paul Hayton on Sat Mar 13 11:09:22 2021
    Hello Paul,

    Saturday March 13 2021, Paul Hayton wrote to Michael Dukelsky:

    7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic
    1byzrpvz.tic
    for
    21:1/213 via 21:1/213
    double free or corruption (fasttop)
    Aborted

    Hopefully, I fixed it. Please pull and rebuild everything.

    OK I am new to Linux but I went into my source files for the following directories and did a 'git pull' for each

    hpt
    htick
    huskylib
    fidoconf
    areafix
    huskybse
    smapi
    hptzip

    I then ran 'make' and 'make install' in this order

    huskylib
    smapi
    fidoconf
    areafix
    hptzip
    hpt
    htick

    Testing htick I see the same error

    7 Mar:13:2021:16:07:14 Forwarding blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66y.tic for 21:1/212 via 21:1/212 7 Mar:13:2021:16:07:14
    Forwarding blocktronics-2021-valentines-day-cards.zip with tic 1bz3g66z.tic for 21:1/213 via 21:1/213 double free or corruption
    (fasttop) Aborted


    But I did have a thought.... should I have copied the new huskymak.xx
    and edited it and placed that in the root huksy directory before I complied the new versions?

    Yes, of course. Did not you do it? If no, please rebuild and if the error persists please send me your FULL config without passwords to my email in tagline.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From andrew clarke@3:633/267 to Michael Dukelsky on Sat Mar 13 19:47:22 2021
    On 2021-03-12 15:29:34, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

    Here foo() can only set its local copy of p to NULL. It can't
    modify the original pointer.

    There's not really any way around this kind of mistake in C, other
    than to run it through a debugger, examine the code and fix it by
    hand.

    We'll wait for Paul to test it.

    Yes. Though I'm not satisfied with nfree() as it feels like it's masking bugs rather than fixing them at the origin. Just my 5c. :)

    --- GoldED+/BSD 1.1.5-b20180707
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Michael Dukelsky on Sat Mar 13 19:53:08 2021
    On 2021-03-12 15:30:48, Michael Dukelsky (2:5020/1042) wrote to Wilfred van Velzen:

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    And the test for NULL isn't necessary, because free() is by
    definition doing nothing if the pointer passed to it is NULL.

    Yes, I know it. It was written long ago and not by me and I do not
    change it because I do not know whether free() always worked as it works now or it did not test the pointer for NULL in some ancient systems.

    Wilfred is right, though I'd prefer nfree() was not used rather than changing it.

    Having a macro modify the variable passed to it just feels like bad code to me. But I will leave it.

    Incidentally I think the "oldest" compiler still supported (properly) by HPT's build files is Open Watcom 2.0. The OW2.0 fork is an active project but its WCL386 compiler is still only C95 compliant, as evident from the internal __STDC_VERSION__ macro being set to 199409.

    Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

    --- GoldED+/BSD 1.1.5-b20180707
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
  • From Michael Dukelsky@2:5020/1042 to andrew clarke on Sat Mar 13 12:55:08 2021
    Hello andrew,

    Saturday March 13 2021, andrew clarke wrote to Michael Dukelsky:

    Here foo() can only set its local copy of p to NULL. It can't
    modify the original pointer.

    There's not really any way around this kind of mistake in C,
    other than to run it through a debugger, examine the code and
    fix it by hand.

    We'll wait for Paul to test it.

    Yes. Though I'm not satisfied with nfree() as it feels like it's
    masking bugs rather than fixing them at the origin. Just my 5c. :)

    No problem. If you want to do it better, just do it. :)

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Michael Dukelsky@2:5020/1042 to andrew clarke on Sat Mar 13 13:11:58 2021
    Hello andrew,

    Saturday March 13 2021, andrew clarke wrote to Michael Dukelsky:

    #define nfree(a) {if(a != NULL) {free(a); a = NULL;}}

    And the test for NULL isn't necessary, because free() is by
    definition doing nothing if the pointer passed to it is NULL.

    Yes, I know it. It was written long ago and not by me and I do
    not change it because I do not know whether free() always worked
    as it works now or it did not test the pointer for NULL in some
    ancient systems.

    Wilfred is right, though I'd prefer nfree() was not used rather than changing it.

    Having a macro modify the variable passed to it just feels like bad
    code to me.

    There's a lot of bad code here.

    But I will leave it.

    So be it.

    Incidentally I think the "oldest" compiler still supported (properly)
    by HPT's build files is Open Watcom 2.0. The OW2.0 fork is an active project but its WCL386 compiler is still only C95 compliant, as
    evident from the internal __STDC_VERSION__ macro being set to 199409.

    Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

    Some persons emerge from time to time who want to build the sources for DOS. Or maybe that was in BINKD echo...

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From andrew clarke@3:633/267 to Michael Dukelsky on Sat Mar 13 21:24:24 2021
    On 2021-03-13 12:55:08, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

    Yes. Though I'm not satisfied with nfree() as it feels like it's
    masking bugs rather than fixing them at the origin. Just my 5c. :)

    No problem. If you want to do it better, just do it. :)

    Maybe. :)

    For now, there are some more important bugs I want to focus on.

    --- GoldED+/BSD 1.1.5-b20180707
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
  • From andrew clarke@3:633/267 to Michael Dukelsky on Sat Mar 13 21:26:38 2021
    On 2021-03-13 13:11:58, Michael Dukelsky (2:5020/1042) wrote to andrew clarke:

    Having a macro modify the variable passed to it just feels like bad
    code to me.

    There's a lot of bad code here.

    Yes.

    Though somehow HPT works (mostly!) despite it all, so I don't like to be too harsh on any of the contributors.

    None of the code I wrote 20 years ago is very good, in hindsight.

    We are only human. :)

    Incidentally I think the "oldest" compiler still supported
    (properly) by HPT's build files is Open Watcom 2.0. The OW2.0 fork
    is an active project but its WCL386 compiler is still only C95
    compliant, as evident from the internal __STDC_VERSION__ macro
    being set to 199409.

    Though C95 is still newer than ISO/IEC 9899:1990, aka C89/C90.

    Some persons emerge from time to time who want to build the sources for DOS. Or maybe that was in BINKD echo...

    Building for 32-bit DOS (DOS4GW) shouldn't be too difficult with OW2.0 now that the OW2.0 NT & OS/2 ports are building well. I've thought about a DOS4GW port but I'm not sure anyone would use it. At some point I may give it a try for a bit of fun and see how far I get, but I'd prefer to focus on fixing bugs and adding features.

    Also it might already be possible to run the Win32 version of HPT under DOS using the HX DOS-Extender. HX is similar to PharLap/286 (one of the first DOS extenders) which provided emulation for a subset of 16-bit OS/2 functions. This allowed you to run a lot of text mode 16-bit OS/2 apps under regular DOS. HX does basically the same, but for a subset of Win32 programs (mostly text apps) on 386+ machines.

    A 16-bit DOS port of HPT is theoretically possible but unrealistic, mostly due to the size of HPT and the DOS 640K limit, and even fewer people would use it compared to a potential DOS4GW version.

    A 16-bit OS/2 port is also theoretically possible but would not be useful to anyone, except as a coding challenge.

    --- GoldED+/BSD 1.1.5-b20180707
    * Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)
  • From Paul Hayton@3:770/100 to Michael Dukelsky on Sun Mar 14 10:17:05 2021
    On 13 Mar 2021 at 11:09a, Michael Dukelsky pondered and said...

    But I did have a thought.... should I have copied the new huskymak.xx and edited it and placed that in the root huksy directory before I complied the new versions?

    Yes, of course. Did not you do it? If no, please rebuild and if the
    error persists please send me your FULL config without passwords to my email in tagline.


    No I did not. I am new to this software. I was under the impression once the huskymak.cfg was set up I didn't need to update that again each time?

    I did copy the new one over, update it (it was no different to my first one) then rebuilt and still hit the same problem

    7 Mar:14:2021:10:13:11 Forwarding blocktronics-2021-calendar.zip with tic 1bz4ug3y.tic for 21:1/212 via 21:1/212
    7 Mar:14:2021:10:13:11 Forwarding blocktronics-2021-calendar.zip with tic 1bz4ug3z.tic for 21:1/213 via 21:1/213
    double free or corruption (fasttop)
    Aborted

    So you want all my config files? Areas, config, links, route... is that correct?

    Best, Paul

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)
  • From Michael Dukelsky@2:5020/1042 to Paul Hayton on Sun Mar 14 15:16:08 2021
    Hello Paul,

    Sunday March 14 2021, Paul Hayton wrote to Michael Dukelsky:

    So you want all my config files? Areas, config, links, route... is
    that correct?

    Exactly.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Moscow, Russia (2:5020/1042)
  • From Paul Hayton@3:770/100 to Michael Dukelsky on Mon Mar 15 09:59:12 2021
    On 14 Mar 2021 at 03:16p, Michael Dukelsky pondered and said...

    Exactly.

    OK

    --- Mystic BBS v1.12 A46 2020/08/26 (Windows/32)
    * Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)