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
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
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.
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
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.
#define nfree(a) {if(a != NULL) {free(a); a = NULL;}}
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.
#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.
#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.
#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! ;)
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.
7 Mar:11:2021:16:26:15 Forwarding fire-34.zip with tic1byzrpvz.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?
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.
#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.
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. :)
#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.
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.
So you want all my config files? Areas, config, links, route... is
that correct?
Exactly.
Sysop: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 138:56:49 |
Calls: | 166 |
Files: | 5,389 |
Messages: | 223,229 |