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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)