X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD
	autolearn=disabled version=3.3.2
Date: Sun, 07 Jan 2018 11:21:48 +0200
Message-Id: <83shbi81n7.fsf@gnu.org>
From: "Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
To: djgpp AT delorie DOT com
In-reply-to: <p2smjv$2lsq$1@adenine.netfront.net> (djgpp@delorie.com)
Subject: Re: smake-1.2.5
References: <p2r0fa$jbp$1 AT adenine DOT netfront DOT net> <83wp0u98sx DOT fsf AT gnu DOT org> <p2smjv$2lsq$1 AT adenine DOT netfront DOT net>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: "david peterac (peters DOT al AT gmx DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
> Date: Sun, 7 Jan 2018 08:43:43 -0000 (UTC)
> 
> Thank You for explanation. The compilation in djdev-2.05 was clean.

It's not a compilation problem, it's a run-time problem.  Some code
calls malloc/free incorrectly and causes corruption of the heap memory
blocks maintained by the library.

According to the library sources, this error message, and the
following SIGABRT, happen in a call to the function 'free' when either
a memory block was released more than once, or if it is otherwise
corrupted.

If you can put a breakpoint in the function 'badcallabort', you should
be able to see the place in the program which triggers this problem.
(For that, you may need to compile nmalloc.c from the library sources
with full debug info.)  Then look at the sources around this place and
try figuring out what caused the problem.

Alternatively, you could try building the program while forcing
Unix-style 'sbrk' algorithm.  The library documentation of
'_crt0_startup_flags' has the details, but basically put something
like this in some source file, outside of any function:

     #include <crt0.h>

     int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;

and then rebuild the program.  This trick could help if smake makes
some assumptions about memory allocation behavior that DJGPP doesn't
uphold by default.  (But since at this point we don't really
understand the cause of the problem, this suggestion is just a stab in
the dark.)