On Sun, May 21, 2023 at 3:29 PM Michael D. Setzer II via users
<users(a)lists.fedoraproject.org> wrote:
On 21 May 2023 at 16:05, Go Canes wrote:
From: Go Canes <letsgonhlcanes0(a)gmail.com>
Date sent: Sun, 21 May 2023 16:05:06 -0400
Subject: Re: Strange error running scripts. without
#!/usr/bin/bash
To: mikes(a)guam.net,
Community support for Fedora users
<users(a)lists.fedoraproject.org>
> On Sat, May 20, 2023 at 10:18 PM Michael D. Setzer II
> <msetzerii(a)gmail.com> wrote:
> > Recently was getting a strange error when running a script that didn't have
#!/usr/bin/bash at top?
> > free(): invalid next size (fast)
> > Aborted (core dumped)
> > Just adding the line fixes the issue, but not sure why??
> > Have run the script before with no such error, but had been a while? Script
was just one line? Now 2 lines.
> > #!/usr/bin/bash
> > boincmgr -e /home/msetzerii/BOINC -d /home/msetzerii/BOINC
>
> I understand that adding the shebang makes it likely that this was
> something to do with the script, but was wondering if somehow the
> "free" error was actually coming from boincmgr.
>
> Also, any chance in the past you invoked it as "sh script.sh" as
> opposed to "./script.sh"? And now you are just doing
"./script.sh"?
> That would explain the change in behavior.
The run_manager script was originally create going back
to 2005, and didn't have the #! line and had worked fine
till this time.
Strange thing is I tried to repeat error later, and it ran
fine without the #! line??
Had seen the same error earlier when I had a 1 line
script, and it gave same error.
Found error in search, and seems to link it to a cpp
program and memory issue. Machine has 16M ram and
has 3.5M Free with 8M in buf/cache so about 4.5M being
currently used by system.
So, not sure why it came up, and now isn't coming up?
This error:
free(): invalid next size (fast)
Indicates that the program getting that error has attempted to free
something that was never malloc'ed.
That generally means that the program has some sort of bug that has a
memory overwrite and overwrites a point that is later attempted to be
free'ed.
Or it has a bug that it is attempting to free something that it never malloc'ed.
Usually if it works most of the time it is a memory overwrite that
gets triggered in some condition.
You would need to figure out what the free error is coming from (if
you can duplicate it). If under any condition it is coming from the
shell then the shell has a bug as this error typically only happens on
a bug. And typically memory overwrites are treated as security bugs,
since if you understand how the overwrite happens you can sometimes
make more interesting things happen. So I would think the error is
more likely coming from one of the programs you are executing.