View Issue Details

IDProjectCategoryView StatusLast Update
0000550LDMud 3.3Compilation, Installationpublic2018-01-29 22:57
Reporterzortek Assigned Tozesstra  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.3 
Fixed in Version3.3.717 
Summary0000550: xptmalloc compilation failure
DescriptionIn file included from xptmalloc.c:20,
                 from xalloc.c:307:
ptmalloc/malloc.h:72:1: warning: "__THROW" redefined
In file included from /usr/include/features.h:329,
                 from /usr/include/sys/types.h:27,
                 from port.h:72,
                 from driver.h:18,
                 from xalloc.c:14:
/usr/include/sys/cdefs.h:47:1: warning: this is the location of the previous definition
In file included from xalloc.c:307:
xptmalloc.c: In function ptmalloc_ref_unused:
xptmalloc.c:252: error: clib_alloc_stat undeclared (first use in this function)
xptmalloc.c:252: error: (Each undeclared identifier is reported only once
xptmalloc.c:252: error: for each function it appears in.)
make: *** [xalloc.o] Error 1
Steps To Reproduce# ./configure --with-malloc=ptmalloc
# make
TagsNo tags attached.

Activities

zesstra

2008-07-08 15:58

administrator   ~0000678

I can reproduce the undeclared 'clib_alloc_stat' on MacOS 10.5.3, though I don't have any warning about the redefinition of __THROW.

zesstra

2008-07-08 16:19

administrator   ~0000681

Looks to me that count_up(clib_alloc_stat, 0); in ptmalloc_ref_unused() in xptmalloc.c should be enclosed in a #if defined(SBRK_OK) ... #endif?

zortek

2008-07-08 16:33

reporter   ~0000682

I've been walking the revs...(currently up through 2368) compiles.
I'm supposing that:
       59 /* PTHREADS need a normal malloc() */
       60 #if defined(SBRK_OK) && defined(USE_PTHREADS)
       61 # undef SBRK_OK
       62 #endif
is the culprit. I'll try wrapping the ptmalloc_ref_unused as suggested.

zesstra

2008-07-08 16:42

administrator   ~0000683

Attached suggested mini patch xptmalloc.diff.

zortek

2008-07-08 16:57

reporter   ~0000685

I updated to rev 2375 and added the wrapper and it fixed the failure for me.

xptmalloc.c
245 #if defined(SBRK_OK)
246 /* Reference a couple of unused variables and functions to avoid
247 * unnecessary warning.
248 */
249 void ptmalloc_ref_unused(void)
250 {
251 in_malloc = 0;
252 print_block(0, 0);
253 count_up(clib_alloc_stat, 0);
254 }
255 #endif

The remaining warnings from xalloc don't make my spleen quiver to overly much. :)

In file included from xptmalloc.c:20,
                 from xalloc.c:307:
ptmalloc/malloc.h:72:1: warning: "__THROW" redefined
In file included from /usr/include/features.h:329,
                 from /usr/include/sys/types.h:27,
                 from port.h:72,
                 from driver.h:18,
                 from xalloc.c:14:
/usr/include/sys/cdefs.h:47:1: warning: this is the location of the previous definition
xalloc.c:115: warning: in_mallocâ defined but not used
xalloc.c:915: warning: print_block defined but not used

zortek

2008-07-08 18:06

reporter   ~0000689

Well, while it compiles, I'm not able to get a parser that doesn't immediately segfault using ptmalloc since rev 2368. (pthreads && ptmalloc)

zesstra

2008-07-08 18:07

administrator   ~0000690

Mhmm, ok, that works as well.
I would not remove the whole function without SBRK_OK, but only the count_up() call, then you won't get the warnings about unused in_malloc and print_block() which is the anyway the whole purpose of ptmalloc_ref_unused().

zesstra

2008-07-08 18:22

administrator   ~0000692

Mhmm, I do not get a segfault, but a working driver (--with-malloc=ptmalloc --enable-use-pthreads).
Your segfault may not be related to this issue. Could you post a stacktrace? (Either by running driver in gdb and issuing a 'bt full' after the segfault or examining a core dump with gdb.)

zortek

2008-07-09 01:16

reporter   ~0000693

GNU gdb Red Hat Linux (6.5-16.el5rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) start
Breakpoint 1 at 0x80b5c27: file main.c, line 251.
Starting program: /mud/trunk/src/ldmud
[Thread debugging using libthread_db enabled]
[New Thread -1208072512 (LWP 18135)]
[Switching to Thread -1208072512 (LWP 18135)]
main (argc=1, argv=0xbf8ffc74) at main.c:251
251 {
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x47faeb57 in _int_free () from /lib/libc.so.6
(gdb) bt full
#0 0x47faeb57 in _int_free () from /lib/libc.so.6
No symbol table info available.
0000001 0x47fb25b0 in free () from /lib/libc.so.6
No symbol table info available.
0000002 0x47f69e52 in _nl_load_locale_from_archive () from /lib/libc.so.6
No symbol table info available.
0000003 0x47f68bd3 in _nl_find_locale () from /lib/libc.so.6
No symbol table info available.
0000004 0x47f686d6 in setlocale () from /lib/libc.so.6
No symbol table info available.
0000005 0x080b5c8e in main (argc=Cannot access memory at address 0x1
) at main.c:269
        i = <value optimized out>
        set = {__val = {8192, 0 <repeats 31 times>}}
        rc = 0

Odd... dumping on:
main.c:269 setlocale(LC_CTYPE, ""); /* Use the locale defined in the LANG env var */

I appologise, I'm still a bit wet behind the ears on this level of exploration. I don't know if I should start a new bug issue or how to document this dialog at this point. I'll try to discover what has changed since rev 2368 that might cause it to fumble at this odd point. Any hints?

2008-07-09 02:26

 

driver.h.diff (608 bytes)   
Index: driver.h
===================================================================
--- driver.h    (revision 2375)
+++ driver.h    (working copy)
@@ -14,8 +14,6 @@

 #include "config.h"

-/* Include the portability headers */
-#include "port.h"

 /* TODO: Some TODO defines */

@@ -134,6 +132,9 @@
 #    define __IPV6__
 #endif

+/* Include the portability headers */
+#include "port.h"
+
 /* TODO: this ctype-stuff might go into lex.h (impl in efun_defs.c) */
 #define _MCTe 0x01 /* escaped character in save/restore object. */
 #define _MCTd 0x02 /* numeric digit                */
driver.h.diff (608 bytes)   

zortek

2008-07-09 02:31

reporter   ~0000694

Last edited: 2008-07-09 02:34

Well, I don't know why yet, but the relocation of port.h upward in driver.h is the break. I returned it to its original location and no more segfaults.

/* Include the portability headers */
#include "port.h"

I supplied a diff and suppose that the original bug report is resolved.

Any hints what might be offending the sequencing? Does this discovery resolve another bug or create a new problem? Was the relocation of the include needed to address a challenge?

Gnomi

2008-07-09 03:14

manager   ~0000697

If you move machine.h back down you may get SBRK_OK defined (it's defined in machine.h which is included in port.h), which is not good if pthreads are used.

Gnomi

2008-07-09 03:23

manager   ~0000698

I can reproduce the segfault and will look into it.

2008-07-09 14:33

 

ptmalloc.diff (1,899 bytes)   
Index: src/xptmalloc.c
===================================================================
--- src/xptmalloc.c	(Revision 2377)
+++ src/xptmalloc.c	(Arbeitskopie)
@@ -235,7 +235,8 @@
  * See above for the *BSD situation.
  */
 
-#if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__)
+#if defined(SBRK_OK) && \
+  !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__)
 #define REPLACE_MALLOC
 #endif
 
@@ -249,7 +250,9 @@
 {
     in_malloc = 0;
     print_block(0, 0);
+#ifdef REPLACE_MALLOC
     count_up(clib_alloc_stat, 0);
+#endif
 }
 
 /***************************************************************************/
Index: src/driver.h
===================================================================
--- src/driver.h	(Revision 2377)
+++ src/driver.h	(Arbeitskopie)
@@ -49,17 +49,26 @@
 #  define GC_SUPPORT 1
 #endif
 
+
 /* Do some of the selected packages require special treatment? */
 
-/* SQLite in the threadsafe mode needs a normal malloc() */
-#if defined(SBRK_OK) && defined(USE_SQLITE) && defined(SQLITE3_USES_PTHREADS)
-#  undef SBRK_OK
-#endif
+/* ptmalloc only works correctly with SBRK_OK right now. */
+#ifdef MALLOC_ptmalloc
+#  ifndef SBRK_OK
+#    define SBRK_OK
+#  endif
+#else // no ptmalloc
+/* SQLite in the threadsafe mode needs a normal malloc() if the allocator is
+ * not ptmalloc*/
+#  if defined(SBRK_OK) && defined(USE_SQLITE) && defined(SQLITE3_USES_PTHREADS)
+#      undef SBRK_OK
+#  endif
+/* PTHREADS need a normal malloc() if the allocator is not ptmalloc */
+#  if defined(SBRK_OK) && defined(USE_PTHREADS)
+#      undef SBRK_OK
+#  endif
+#endif // MALLOC_ptmalloc
 
-/* PTHREADS need a normal malloc() */
-#if defined(SBRK_OK) && defined(USE_PTHREADS)
-#  undef SBRK_OK
-#endif
 
 /* When we have allocation tracing, the allocator annotates every
  * allocation with the source filename and line where the allocation
ptmalloc.diff (1,899 bytes)   

zesstra

2008-07-09 14:37

administrator   ~0000708

Gnomi found out, that the root cause for the crash are name clashes between our implementation of ptmalloc and the one in glibc. In that sense, it is a different bug than this one.
However, this problem occurs only, if it is not possible to replace the system malloc (glibcs ptmalloc) by our own ptmalloc.
The recent changes had the side effect to undefine SBRK_OK unnecessarily in some cases (use of pthreads) and thus prevent to replace malloc.
The attached patch enforces SBRK_OK in driver.h, if ptmalloc is used as memory allocator, so that the driver always uses its built-in ptalloc. While we should discuss how to deal with the bigger problem of name clashes in our code and the glibc, this should be a work-around for most users.
Additionally, clib_alloc_stat in xptmalloc.c is only used if REPLACE_MALLOC is defined.
Could you please check ptmalloc.diff?

zortek

2008-07-09 15:12

reporter   ~0000710

Rev. 2377 and applied ptmalloc.diff. Works for me. Thanks for the help and learning opportunity.

zesstra

2008-07-16 17:36

administrator   ~0000734

I applied the patch in r2390 which should resolve this bug.
Of course, the underlying problem with the name collisions of our ptmalloc and glibc ptmalloc (0000552) remain, that has to be solved later on.

Issue History

Date Modified Username Field Change
2008-07-08 14:09 zortek New Issue
2008-07-08 15:58 zesstra Note Added: 0000678
2008-07-08 15:58 zesstra Status new => confirmed
2008-07-08 15:58 zesstra Steps to Reproduce Updated
2008-07-08 16:19 zesstra Note Added: 0000681
2008-07-08 16:33 zortek Note Added: 0000682
2008-07-08 16:42 zesstra File Added: xptmalloc.diff
2008-07-08 16:42 zesstra Note Added: 0000683
2008-07-08 16:57 zortek Note Added: 0000685
2008-07-08 18:06 zortek Note Added: 0000689
2008-07-08 18:07 zesstra Note Added: 0000690
2008-07-08 18:07 zesstra Assigned To => zesstra
2008-07-08 18:07 zesstra Status confirmed => assigned
2008-07-08 18:22 zesstra Note Added: 0000692
2008-07-09 01:16 zortek Note Added: 0000693
2008-07-09 02:26 zortek File Added: driver.h.diff
2008-07-09 02:31 zortek Note Added: 0000694
2008-07-09 02:34 zortek Note Edited: 0000694
2008-07-09 03:14 Gnomi Note Added: 0000697
2008-07-09 03:23 Gnomi Note Added: 0000698
2008-07-09 14:33 zesstra File Deleted: xptmalloc.diff
2008-07-09 14:33 zesstra File Added: ptmalloc.diff
2008-07-09 14:37 zesstra Note Added: 0000708
2008-07-09 14:37 zesstra Status assigned => feedback
2008-07-09 15:12 zortek Note Added: 0000710
2008-07-16 17:36 zesstra Status feedback => resolved
2008-07-16 17:36 zesstra Fixed in Version => 3.3.717
2008-07-16 17:36 zesstra Resolution open => fixed
2008-07-16 17:36 zesstra Note Added: 0000734
2009-04-14 14:14 zesstra Project LDMud => LDMud 3.3
2010-11-16 10:42 zesstra Source_changeset_attached => ldmud.git master add1b9d5
2018-01-29 19:59 zesstra Source_changeset_attached => ldmud.git master add1b9d5
2018-01-29 22:57 zesstra Source_changeset_attached => ldmud.git master add1b9d5