bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

[forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html]

From: Svante Signell <svante.signell@gmail.com>
To: emacs-devel@gnu.org
Date: Wed, 02 Nov 2016 15:16:54 +0100

Since a long time emacs FTBFS due to unknown reasons. The latest version
building was Debian 24.5+1-5, from 27 Nov 2015. Even before successful builds
were by pure luck. One suspicious issue is that emacs use sbrk() for memory
allocation, right? Notably sbrk() is not fool-proof as implemented for Hurd in
glibc. Use of sbrk is found in files alloc.c, unexelf.c and gmalloc.c, which are
all compiled. Avoiding compilation of ralloc.c with 0001-Default-REL_ALLOC-to-
no.patch did not improve the situation.

First time I compiled emacs 25.1 from upstream it passed, second time not.
Compiling Debian versions almost always fail. Moslty the build fails with temacs
failing to execute: Killed. In my opionion it's a real loss not to gave a modern
version of emacs25 available for use in GNU/Hurd (not everybody use vi).

Do anybody of you have an idea on how to solve this problem? Are there patches
available already to try with?

Thanks in advance :)

bug#24857: Fwd: Re: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

-------- Forwarded Message --------
Subject: 	Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: 	Wed, 02 Nov 2016 17:39:51 +0200
From: 	Eli Zaretskii <eliz@gnu.org>
Reply-To: 	Eli Zaretskii <eliz@gnu.org>
To: 	svante.signell@gmail.com
CC: 	emacs-devel@gnu.org



> From: Svante Signell <svante.signell@gmail.com>
> Date: Wed, 02 Nov 2016 15:16:54 +0100
>
> First time I compiled emacs 25.1 from upstream it passed, second time not.
> Compiling Debian versions almost always fail. Moslty the build fails with temacs
> failing to execute: Killed. In my opionion it's a real loss not to gave a modern
> version of emacs25 available for use in GNU/Hurd (not everybody use vi).
>
> Do anybody of you have an idea on how to solve this problem?

My suggestion is to run the failing temacs command line under GDB and
see where it crashes.

The best way to communicate this information is to file a bug report,
using "M-x report-emacs-bug RET" (in some version of Emacs you have
that is operable; if not, just email the details to
bug-gnu-emacs@gnu.org).

bug#24857: Fwd: Re: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

-------- Forwarded Message --------
Subject: 	Re: emacs24/25 FTBFS since a long time on GNU/Hurd
Date: 	Wed, 02 Nov 2016 16:51:44 +0100
From: 	Svante Signell <svante.signell@gmail.com>
Reply-To: 	svante.signell@gmail.com
Organization: 	Home
To: 	Eli Zaretskii <eliz@gnu.org>
CC: 	emacs-devel@gnu.org



On Wed, 2016-11-02 at 17:39 +0200, Eli Zaretskii wrote:
> >
> > From: Svante Signell <svante.signell@gmail.com>
> > Date: Wed, 02 Nov 2016 15:16:54 +0100
> >
> > First time I compiled emacs 25.1 from upstream it passed, second time not.
> > Compiling Debian versions almost always fail. Moslty the build fails with
> > temacs
> > failing to execute: Killed. In my opionion it's a real loss not to gave a
> > modern
> > version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> >
> > Do anybody of you have an idea on how to solve this problem?
> My suggestion is to run the failing temacs command line under GDB and
> see where it crashes.

Hi, attached is a traceback from gdb. Edited to remove thousands of loops, as
indicated in that file.

> The best way to communicate this information is to file a bug report,
> using "M-x report-emacs-bug RET" (in some version of Emacs you have
> that is operable; if not, just email the details to
> bug-gnu-emacs@gnu.org).

A bug was already filed by Paul Eggert, https://debbugs.gnu.org/cgi/bugreport.cg
i?bug=24857

Thanks anyway.


[-- Attachment #2: gdb_edited.txt --]
[-- Type: text/plain, Size: 15677 bytes --]

gdb ./temacs
(gdb) run --batch --load loadup bootstrap
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/src/temacs --batch --load loadup bootstrap

Thread 4 received signal ?, Unknown signal.
0x051dcc63 in __vm_allocate (target_task=1, address=0x2d03c, size=12288, anywhere=0)
    at /home/srs/DEBs/glibc/2.24/glibc-2.24/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
54      /home/srs/DEBs/glibc/2.24/glibc-2.24/build-tree/hurd-i386-libc/mach/vm_allocate.c: No such file or directory.
(gdb) thread apply all bt full

Thread 4 (Thread 25492.4):
#0  0x051dcc63 in __vm_allocate (target_task=1, address=0x2d03c, size=12288, anywhere=0)
    at /home/srs/DEBs/glibc/2.24/glibc-2.24/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
        err = <optimized out>
#1  0x052ef5f2 in _hurd_set_brk (addr=139247616) at ../sysdeps/mach/hurd/brk.c:116
        alloc_start = 139235328
        err = <optimized out>
        pagend = 139247616
        pagebrk = 139235328
        rlimit = <optimized out>
#2  0x052efaaf in __sbrk (increment=12288) at ../sysdeps/mach/hurd/sbrk.c:33
        result = 0x84c9000
#3  0x0820202c in __default_morecore (increment=12288) at gmalloc.c:1532
        result = <optimized out>
#4  0x08201e35 in align (size=size@entry=12288) at gmalloc.c:445
        result = <optimized out>
        adj = <optimized out>
#5  0x08201fa3 in malloc_initialize_1 () at gmalloc.c:571
No locals.
#6  0x082020fd in __malloc_initialize () at gmalloc.c:597
No locals.
#7  gmalloc (size=100) at gmalloc.c:934
        hook = <optimized out>
#8  0x082033d5 in malloc (size=100) at gmalloc.c:1822
No locals.
#9  0x05262c8c in _IO_vasprintf (result_ptr=0x2d228, 
    format=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    args=0x2d1f8 "\377A6\005\377A6\005\027\317\026\005\034") at vasprintf.c:47
        string = <optimized out>
        sf = {_sbf = {_f = {_flags = 0, _IO_read_ptr = 0x0, 
              _IO_read_end = 0x84cc000 "\340", <incomplete sequence \302>, 
              _IO_read_base = 0x84c9000 "\177ELF\001\001\001", 
              _IO_write_base = 0x43 <error: Cannot access memory at address 0x43>, 
              _IO_write_ptr = 0x0, 
              _IO_write_end = 0x51f9f29 <__hurd_sigstate_lock+9> "\201\303\327\300\035", 
              _IO_buf_base = 0x51dd116 <__mach_msg+54> "\203\304 \205\300tF\366D$4@tj\367D$4", _IO_buf_end = 0x2d1b0 "", 
              _IO_save_base = 0x3 <error: Cannot access memory at address 0x3>, 
              _IO_backup_base = 0x30 <error: Cannot access memory at address 0x30>, 
              _IO_save_end = 0x20 <error: Cannot access memory at address 0x20>, 
              _markers = 0x253, _chain = 0x0, _fileno = 0, _flags2 = 1667393900, 
              _old_offset = 7302446, _cur_column = 23165, _vtable_offset = 54 '6', 
              _shortbuf = "\005", _lock = 0x521d525 <__current_locale_name+5>, 
              _offset = 375144790433592650, _codecvt = 0x53d86b4 <root>, 
              _wide_data = 0x51dd0e9 <__mach_msg+9>, _freeres_list = 0x7fd9000, 
              _freeres_buf = 0x516cf2c <__PRETTY_FUNCTION__.9369>, __pad5 = 134505880, 
              _mode = 16961000, 
              _unused2 = "\230\271\374\a\260\321\002\000\003\000\000\000\060\000\000\000\253\271\374\aS\002\000\000\000\000\000\000\000\000\000\000l\271\374\ap\321\002"}, 
            vtable = 0x40000009}, _s = {_allocate_buffer = 0x0, _free_buffer = 0x0}}
        ret = <optimized out>
        needed = <optimized out>
        allocated = <optimized out>
#10 0x05244694 in ___asprintf (string_ptr=0x2d228, 
    format=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n") at asprintf.c:35
        arg = 0x2d1f8 "\377A6\005\377A6\005\027\317\026\005\034"
        done = 184380
#11 0x0521d64c in __assert_fail_base (
    fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", 
    line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:57
        str = 0x0
        total = 86103528
#12 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", 
    file=0x516cf17 "./pthread/pt-self.c", line=28, 
    function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:101
No locals.
#13 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#14 0x05224e8e in raise (signo=6) at ../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#15 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5369100, sa_sigaction = 0x5369100}, 
          sa_mask = 87441919, sa_flags = 87908352}
        sigs = 32
#16 0x0521d6f4 in __assert_fail_base (
    fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", 
    line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:92
        str = 0x0
        total = 86103528
#17 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", 
    file=0x516cf17 "./pthread/pt-self.c", line=28, 
    function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:101
No locals.
#18 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#19 0x05224e8e in raise (signo=6) at ../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#20 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5369100, sa_sigaction = 0x5369100}, 
          sa_mask = 87441919, sa_flags = 87908352}
        sigs = 32
#16+17+18+19+20 loops from here
...
#374446 0x0521d6f4 in __assert_fail_base (fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:92
        str = 0x0
        total = 86103528
#374447 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c", line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:101
No locals.
#374448 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#374449 0x05224e8e in raise (signo=6) at ../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#374450 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x53d6000, sa_sigaction = 0x53d6000}, sa_mask = 85383452, sa_flags = 16959788}
        sigs = 32
#374451 0x0521d6f4 in __assert_fail_base (fmt=0x5369140 "%s%s%s:%u: %s%sUnexpected error: %s.\n", assertion=0x53646db "Cannot allocate memory", file=0x516d8f0 "../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c <__PRETTY_FUNCTION__.9436> "_init_routine") at assert.c:92
        str = 0x0
        total = 86103528
#374452 0x0521d7bf in __assert_perror_fail (errnum=1073741836, file=0x516d8f0 "../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c <__PRETTY_FUNCTION__.9436> "_init_routine") at assert-perr.c:35
        errbuf = "\001\000\000\000\300r\375\001@\311\002\001'\336\000\000\360\333\000\000Е\000\000\240\061\035\005\240\061\035\005\001\000\000\000\024\312\002\001\000 \000\000\000\000\000\000\001\000\000\000v\032i\t\000\000\000\000\000\000\000\000\251\224\000\000\000\260\002\000\f\001\034\005\330\310\350\004\236\002\000\000˝\000\000\005\000\000\000\001\000\000\000$I\034\005\020\225\000\000\310/\374\a;\316\034\005$\312\002\001 \312\002\001\000 \000\000\310\f\004\b}\000\000\000;\316\034\005\223\365\034\005j\315yy\251\224\000\000\000\260\002\000<\020\374\ax\204\336\a\375\000\000\000˝\000\000\005\000\000\000\001\000\000\000d!\374\aЕ\000\000\255\062\035\005\255\062\035\005t\312\002\001p\312\002\001\240\061\035\005"...
        e = 0x53646db "Cannot allocate memory"
#374453 0x0516bb99 in _init_routine (stack=0x0) at ../libpthread/sysdeps/mach/hurd/pt-sysdep.c:67
        thread = 0x0
        err = <optimized out>
        attr = {__schedparam = {__sched_priority = 0}, __stackaddr = 0x7, __stacksize = 1, __guardsize = 85910395, __detachstate = (unknown: 87916512), __inheritsched = (unknown: 3084914), __contentionscope = (unknown: 1866732), __schedpolicy = 85375740}
        attrp = 0x0
#374454 0x05210a33 in init (data=0x102cdf0) at ../sysdeps/mach/hurd/i386/init-first.c:213
        newsp = <optimized out>
        od = <optimized out>
        argv = 0x102cdf4
        argc = <optimized out>
        envp = 0x102ce68
        d = 0x102ce68
#374455 _dl_init_first (argc=<optimized out>) at ../sysdeps/mach/hurd/i386/init-first.c:327
No locals.
#374456 0x00001e06 in _dl_start_user () from /lib/ld.so
        audit_list = 0x0
        _dl_rtld_libname2 = {name = 0x0, next = 0x0, dont_free = 0}
        library_path = 0x0
        any_debug = 0
        tls_init_tp_called = true
        preloadlist = 0x0
        version_info = 0
        _dl_rtld_libname = {name = 0x8048154 "/lib/ld.so", next = 0x2b7ec <newname>, dont_free = 0}
        _dl_argv = 0x102cdf4
        _dl_starting_up = 1
        _dl_skip_args = 0
        _rtld_global = {_dl_ns = {{_ns_loaded = 0x2b938, _ns_nloaded = 125, _ns_main_searchlist = 0x2ba94, _ns_global_scope_alloc = 0, _ns_unique_sym_table = {lock = {lock = 0, cnt = 0, owner = 0x0}, entries = 0x86fd000, size = 251, n_elements = 98, free = 0x18740 <free>}, _ns_debug = {r_version = 0, r_map = 0x0, r_brk = 0, r_state = RT_CONSISTENT, r_ldbase = 0}}, {_ns_loaded = 0x0, _ns_nloaded = 0, _ns_main_searchlist = 0x0, _ns_global_scope_alloc = 0, _ns_unique_sym_table = {lock = {lock = 0, cnt = 0, owner = 0x0}, entries = 0x0, size = 0, n_elements = 0, free = 0x0}, _ns_debug = {r_version = 0, r_map = 0x0, r_brk = 0, r_state = RT_CONSISTENT, r_ldbase = 0}} <repeats 15 times>}, _dl_nns = 1, _dl_load_lock = {lock = 0, cnt = 0, owner = 0x0}, _dl_load_write_lock = {lock = 0, cnt = 0, owner = 0x0}, _dl_load_adds = 125, _dl_initfirst = 0x0, _dl_profile_map = 0x0, _dl_num_relocations = 25252, _dl_num_cache_relocations = 36248, _dl_all_dirs = 0x5708378, _dl_error_catch_tsd = 0x1e40 <_dl_initial_error_catch_tsd>, _dl_rtld_map = {l_addr = 4096, l_name = 0x8048154 "/lib/ld.so", l_ld = 0x2af04, l_next = 0x4e8cb90, l_prev = 0x4e8c8d8, l_real = 0x2b4bc <_rtld_global+1084>, l_ns = 0, l_libname = 0x2b808 <_dl_rtld_libname>, l_info = {0x0, 0x0, 0x2af44, 0x2af3c, 0x2af0c, 0x2af1c, 0x2af24, 0x0, 0x0, 0x0, 0x2af2c, 0x2af34, 0x0, 0x0, 0x2af04, 0x0, 0x0, 0x2af5c, 0x2af64, 0x2af6c, 0x2af4c, 0x0, 0x0, 0x2af54, 0x0 <repeats 12 times>, 0x2af7c, 0x2af74, 0x0, 0x2af8c, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2af84, 0x0 <repeats 25 times>, 0x2af14}, l_phdr = 0x1034, l_entry = 0, l_phnum = 7, l_ldnum = 0, l_searchlist = {r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x0, r_nlist = 0}, l_loader = 0x0, l_versions = 0x8043580, l_nversions = 6, l_nbuckets = 37, l_gnu_bitmask_idxbits = 7, l_gnu_shift = 8, l_gnu_bitmask = 0x12a0, {l_gnu_buckets = 0x12c0, l_chain = 0x12c0}, {l_gnu_chain_zero = 0x1350, l_buckets = 0x1350}, l_direct_opencount = 0, l_type = lt_library, l_relocated = 1, l_init_called = 0, l_global = 1, l_reserved = 0, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, l_auditing = 0, l_audit_any_plt = 0, l_removed = 0, l_contiguous = 0, l_symbolic_in_local_scope = 0, l_free_initfini = 0, l_rpath_dirs = {dirs = 0x0, malloced = 0}, l_reloc_result = 0x0, l_versyms = 0x1982, l_origin = 0x0, l_map_start = 4096, l_map_end = 178484, l_text_end = 129229, l_scope_mem = {0x0, 0x0, 0x0, 0x0}, l_scope_max = 0, l_scope = 0x0, l_local_scope = {0x0, 0x0}, l_file_id = {dev = 0, ino = 0}, l_runpath_dirs = {dirs = 0x0, malloced = 0}, l_initfini = 0x0, l_reldeps = 0x0, l_reldepsmax = 0, l_used = 1, l_feature_1 = 0, l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {plt = 0, gotplt = 0, tlsdesc_table = 0x0}, l_lookup_cache = {sym = 0x157c, type_class = 1, value = 0x4e8c8d8, ret = 0x51c8024}, l_tls_initimage = 0x0, l_tls_initimage_size = 0, l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0, l_tls_offset = 0, l_tls_modid = 0, l_tls_dtor_count = 0, l_relro_addr = 171200, l_relro_size = 832, l_serial = 0, l_audit = 0x2b714 <_rtld_global+1684>}, audit_data = {{cookie = 0, bindflags = 0} <repeats 16 times>}, _dl_make_stack_executable_hook = 0x13480 <_dl_make_stack_executable>, _dl_stack_flags = 7, _dl_tls_dtv_gaps = false, _dl_tls_max_dtv_idx = 8, _dl_tls_dtv_slotinfo_list = 0x8045ad0, _dl_tls_static_nelem = 8, _dl_tls_static_size = 2248, _dl_tls_static_used = 520, _dl_tls_static_align = 4, _dl_initial_dtv = 0x80465e0, _dl_tls_generation = 1, _dl_init_static_tls = 0xbb00 <_dl_nothread_init_static_tls>, _dl_wait_lookup_done = 0x0, _dl_scope_free_list = 0x0, _dl_thread_gscope_count = 0}
        __stack_chk_guard = 4278845440
        __pointer_chk_guard_local = 4278845440
        _rtld_global_ro = {_dl_debug_mask = 0, _dl_osversion = 0, _dl_platform = 0x0, _dl_platformlen = 0, _dl_pagesize = 4096, _dl_inhibit_cache = 0, _dl_initial_searchlist = {r_list = 0x8040cc8, r_nlist = 125}, _dl_clktck = 0, _dl_verbose = 0, _dl_debug_fd = 2, _dl_lazy = 1, _dl_bind_not = 0, _dl_dynamic_weak = 0, _dl_fpu_control = 895, _dl_correct_cache_id = 3, _dl_hwcap = 0, _dl_hwcap_mask = 67141632, _dl_x86_cpu_features = {kind = arch_kind_unknown, max_cpuid = 0, cpuid = {{eax = 0, ebx = 0, ecx = 0, edx = 0}, {eax = 0, ebx = 0, ecx = 0, edx = 0}, {eax = 0, ebx = 0, ecx = 0, edx = 0}}, family = 0, model = 0, feature = {0}}, _dl_x86_cap_flags = {"fpu\000\000\000\000", "vme\000\000\000\000", "de\000\000\000\000\000", "pse\000\000\000\000", "tsc\000\000\000\000", "msr\000\000\000\000", "pae\000\000\000\000", "mce\000\000\000\000", "cx8\000\000\000\000", "apic\000\000\000", "10\000\000\000\000\000", "sep\000\000\000\000", "mtrr\000\000\000", "pge\000\000\000\000", "mca\000\000\000\000", "cmov\000\000\000", "pat\000\000\000\000", "pse36\000\000", "pn\000\000\000\000\000", "clflush", "20\000\000\000\000\000", "dts\000\000\000\000", "acpi\000\000\000", "mmx\000\000\000\000", "fxsr\000\000\000", "sse\000\000\000\000", "sse2\000\000\000", "ss\000\000\000\000\000", "ht\000\000\000\000\000", "tm\000\000\000\000\000", "ia64\000\000\000", "pbe\000\000\000\000"}, _dl_x86_platforms = {"i386", "i486", "i586", "i686"}, _dl_inhibit_rpath = 0x0, _dl_origin_path = 0x102e6d7 "/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/src", _dl_use_load_bias = 4294967295, _dl_profile = 0x0, _dl_profile_output = 0x1f8e0 "/var/tmp", _dl_trace_prelink = 0x0, _dl_trace_prelink_map = 0x0, _dl_init_all_dirs = 0x5708378, _dl_hwcap2 = 0, _dl_debug_printf = 0x10d50 <_dl_debug_printf>, _dl_catch_error = 0xfca0 <_dl_catch_error>, _dl_signal_error = 0xfa30 <_dl_signal_error>, _dl_mcount = 0x11f60 <_dl_mcount>, _dl_lookup_symbol_x = 0xa250 <_dl_lookup_symbol_x>, _dl_check_caller = 0x134f0 <_dl_check_caller>, _dl_open = 0x13ad0 <_dl_open>, _dl_close = 0x15e40 <_dl_close>, _dl_tls_get_addr_soft = 0x13180 <_dl_tls_get_addr_soft>, _dl_audit = 0x0, _dl_naudit = 0}
        _dl_argc = 5
#374457 0x00000005 in ?? ()
No symbol table info available.
#374458 0x0102d000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 2 Nov 2016 08:20:59 -0700
> Cc: Svante Signell <svante.signell@gmail.com>
> 
> [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00055.html]
> 
> From: Svante Signell <svante.signell@gmail.com>
> To: emacs-devel@gnu.org
> Date: Wed, 02 Nov 2016 15:16:54 +0100
> 
> Since a long time emacs FTBFS due to unknown reasons. The latest version
> building was Debian 24.5+1-5, from 27 Nov 2015. Even before successful builds
> were by pure luck. One suspicious issue is that emacs use sbrk() for memory
> allocation, right? Notably sbrk() is not fool-proof as implemented for Hurd in
> glibc. Use of sbrk is found in files alloc.c, unexelf.c and gmalloc.c, which are
> all compiled. Avoiding compilation of ralloc.c with 0001-Default-REL_ALLOC-to-
> no.patch did not improve the situation.

The posted backtrace indicates the problem is with inability to
allocate memory:

  #374452 0x0521d7bf in __assert_perror_fail (errnum=1073741836, file=0x516d8f0 "../libpthread/sysdeps/mach/hurd/pt-sysdep.c", line=67, function=0x516d91c <__PRETTY_FUNCTION__.9436> "_init_routine") at assert-perr.c:35
	  errbuf = "\001\000\000\000\300r\375\001@\311\002\001'\336\000\000\360\333\000\000Ð\225\000\000\240\061\035\005\240\061\035\005\001\000\000\000\024\312\002\001\000 \000\000\000\000\000\000\001\000\000\000v\032i\t\000\000\000\000\000\000\000\000\251\224\000\000\000\260\002\000\f\001\034\005\330\310\350\004\236\002\000\000Ë\235\000\000\005\000\000\000\001\000\000\000$I\034\005\020\225\000\000\310/\374\a;\316\034\005$\312\002\001 \312\002\001\000 \000\000\310\f\004\b}\000\000\000;\316\034\005\223\365\034\005j\315yy\251\224\000\000\000\260\002\000<\020\374\ax\204\336\a\375\000\000\000Ë\235\000\000\005\000\000\000\001\000\000\000d!\374\aÐ\225\000\000\255\062\035\005\255\062\035\005t\312\002\001p\312\002\001\240\061\035\005"...
	  e = 0x53646db "Cannot allocate memory"
  #374453 0x0516bb99 in _init_routine (stack=0x0) at ../libpthread/sysdeps/mach/hurd/pt-sysdep.c:67
	  thread = 0x0
	  err = <optimized out>
	  attr = {__schedparam = {__sched_priority = 0}, __stackaddr = 0x7, __stacksize = 1, __guardsize = 85910395, __detachstate = (unknown: 87916512), __inheritsched = (unknown: 3084914), __contentionscope = (unknown: 1866732), __schedpolicy = 85375740}
	  attrp = 0x0
  #374454 0x05210a33 in init (data=0x102cdf0) at ../sysdeps/mach/hurd/i386/init-first.c:213

Btw, what happened between frame #0 and frame #374454?  Was that some
infinite loop trying to print an error message, which caused an
attempt to allocate memory, which tried to print an error message, and
so on and so forth?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Wed, 2016-11-02 at 18:46 +0200, Eli Zaretskii wrote:
> > 
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Wed, 2 Nov 2016 08:20:59 -0700
> > Cc: Svante Signell <svante.signell@gmail.com>
> > 
> > [forwarded from http://lists.gnu.org/archive/html/emacs-devel/2016-11/msg000
> > 55.html]
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > To: emacs-devel@gnu.org
> > Date: Wed, 02 Nov 2016 15:16:54 +0100
> > 
> The posted backtrace indicates the problem is with inability to
> allocate memory:

Yes!

> Btw, what happened between frame #0 and frame #374454?  Was that some
> infinite loop trying to print an error message, which caused an
> attempt to allocate memory, which tried to print an error message, and
> so on and so forth?

#16 0x0521d6f4 in __assert_fail_base (
    fmt=0x5369100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x516cc49 "__pthread_threads", file=0x516cf17 "./pthread/pt-self.c
", 
    line=28, function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at 
assert.c:92
        str = 0x0
        total = 86103528
#17 0x0521d75a in __assert_fail (assertion=0x516cc49 "__pthread_threads", 
    file=0x516cf17 "./pthread/pt-self.c", line=28, 
    function=0x516cf2c <__PRETTY_FUNCTION__.9369> "__pthread_self") at assert.c:
101
No locals.
#18 0x05168696 in __pthread_self () at ./pthread/pt-self.c:28
        thread = <optimized out>
        self = <optimized out>
        self = <optimized out>
#19 0x05224e8e in raise (signo=6) at
../sysdeps/../libpthread/sysdeps/generic/raise.c:37
        err = <optimized out>
#20 0x052276cf in abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5369100, sa_sigaction =
0x519369100}, 
          sa_mask = 87441919, sa_flags = 87908352}
        sigs = 32

#16+17+18+19+20 loops from here:...

That was a bug in raise looping indefinitely due to a failed assertion, now
fixed.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Wed, 2016-11-02 at 18:38 +0100, Svante Signell wrote:
> On Wed, 2016-11-02 at 18:46 +0200, Eli Zaretskii wrote:
...
> > The posted backtrace indicates the problem is with inability to
> > allocate memory:
> Yes!

More info: Forcing the use of SYSTEM_MALLOC instead of GNU_MALLOC and commenting
out sbrk usage in alloc.c and unexelf.c as in https://debbugs.gnu.org/cgi/bugrep
ort.cgi?bug=24892#15 temacs does no longer freak out (Killed). Looking at the
build log vm-limit.c and gmalloc.c are no longer compiled.

Now there is a SEGFAULT in dumped-emacs:

/usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[4]: Entering directory '/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-
x/lisp'
  ELC      emacs-lisp/macroexp.elc
/bin/bash: line 1: 27157 Segmentation fault      EMACSLOADPATH=
'../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval "(setq max-
lisp-eval-depth 2200)" --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
emacs-lisp/macroexp.el

I've traced it down to the make_float() function in alloc.c:
if (float_free_list = 0x0) <FALSE>
if (float_block_index=27 == FLOAT_BLOCK_SIZE=124): <FALSE>
Next statement: XSETFLOAT (val, &float_block->floats[float_block_index]);
is called with an invalid address:
(gdb) p float_block
$2 = (struct float_block *) 0xad8c00
(gdb) p *float_block
Cannot access memory at address 0xad8c00
causing the segfault later on.

Is the static struct float_block *float_block allocated on the heap?
0xad8c00 = 10.847 MiB is much smaller that available memory.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: 24857@debbugs.gnu.org
> Date: Thu, 10 Nov 2016 12:57:56 +0100
> 
> More info: Forcing the use of SYSTEM_MALLOC instead of GNU_MALLOC and commenting
> out sbrk usage in alloc.c and unexelf.c as in https://debbugs.gnu.org/cgi/bugrep
> ort.cgi?bug=24892#15 temacs does no longer freak out (Killed). Looking at the
> build log vm-limit.c and gmalloc.c are no longer compiled.
> 
> Now there is a SEGFAULT in dumped-emacs:
> 
> /usr/bin/make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
> make[4]: Entering directory '/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-
> x/lisp'
>   ELC      emacs-lisp/macroexp.elc
> /bin/bash: line 1: 27157 Segmentation fault      EMACSLOADPATH=
> '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval "(setq max-
> lisp-eval-depth 2200)" --eval '(setq load-prefer-newer t)' -f batch-byte-compile 
> emacs-lisp/macroexp.el
> 
> I've traced it down to the make_float() function in alloc.c:
> if (float_free_list = 0x0) <FALSE>
> if (float_block_index=27 == FLOAT_BLOCK_SIZE=124): <FALSE>
> Next statement: XSETFLOAT (val, &float_block->floats[float_block_index]);
> is called with an invalid address:
> (gdb) p float_block
> $2 = (struct float_block *) 0xad8c00
> (gdb) p *float_block
> Cannot access memory at address 0xad8c00
> causing the segfault later on.
> 
> Is the static struct float_block *float_block allocated on the heap?
> 0xad8c00 = 10.847 MiB is much smaller that available memory.

Sounds like the memory-related problems are not over yet.

Did you try to invoke temacs, and work in that?  IOW, try this:

  ./src/temacs -Q

It will load a bunch pf Lisp files, and should then present a normal
frame, where you should be able to work as usual.  If that does work
on Hurd, I'm pretty sure the problem is with unexec and dumping Emacs.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Thu, 2016-11-10 at 18:00 +0200, Eli Zaretskii wrote:
> > 
> Did you try to invoke temacs, and work in that?  IOW, try this:
> 
>   ./src/temacs -Q
> 
> It will load a bunch pf Lisp files, and should then present a normal
> frame, where you should be able to work as usual.  If that does work
> on Hurd, I'm pretty sure the problem is with unexec and dumping Emacs.

I get with ./temacs -Q -nw a frame and on the bottom line:
emacs-x is built first in the Debian build 25.1-2:

logging in to the kvm box with ssh ... gives

Symbol’s function definition is void: internal-echo-keystrokes-prefix
and then a freeze

logging in with ssh -Y ... gives
Loading loadup.el (source)...
Using load-path (/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/lisp)-------
----------
Loading emacs-lisp/byte-run (source)...nternal-echo-keystrokes-prefix
Loading emacs-lisp/byte-run (source)...done
Loading emacs-lisp/backquote (source)...
Loading emacs-lisp/backquote (source)...done
Loading subr (source)...
Loading subr (source)...done
Loading version (source)...
Symbol’s function definition is void: pcase

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Thu, 10 Nov 2016 21:35:53 +0100
> 
> I get with ./temacs -Q -nw a frame and on the bottom line:
> emacs-x is built first in the Debian build 25.1-2:

Why did you use -nw?  I meant for you to try the usual GUI session.

> logging in to the kvm box with ssh ... gives
> 
> Symbol’s function definition is void: internal-echo-keystrokes-prefix
> and then a freeze
> 
> logging in with ssh -Y ... gives
> Loading loadup.el (source)...
> Using load-path (/home/srs/DEBs/emacs/emacs25-25.1+1/debian/build-x/lisp)-------
> ----------
> Loading emacs-lisp/byte-run (source)...nternal-echo-keystrokes-prefix
> Loading emacs-lisp/byte-run (source)...done
> Loading emacs-lisp/backquote (source)...
> Loading emacs-lisp/backquote (source)...done
> Loading subr (source)...
> Loading subr (source)...done
> Loading version (source)...
> Symbol’s function definition is void: pcase

Are you building from the Git repository?  If so, don't: doing that
requires byte-compiling all the Lisp files, which would be difficult
given your problems.

Instead, try building an official 25.1 release tarball, then invoke
temacs built there, and see if it works.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 09:48 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> > Date: Thu, 10 Nov 2016 21:35:53 +0100
> > 
> > 
> Are you building from the Git repository?  If so, don't: doing that
> requires byte-compiling all the Lisp files, which would be difficult
> given your problems.

I did build from today's git. After setting libsystemd to off
OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
the build was successful: all three built executables: temacs, bootstrap-emacs,
emacs works fine.

Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:
Dumping under the name emacs
45802 pure bytes used
mv -f emacs bootstrap-emacs
make -C ../lisp compile-first EMACS="../src/bootstrap-emacs"
make[2]: Entering directory '/home/srs/DEBs/emacs/GIT/emacs/lisp'
  ELC      emacs-lisp/macroexp.elc
*** Error in `../src/bootstrap-emacs': corrupted double-linked list: 0x08ecb960
***
Fatal error 6: Aborted
Backtrace:
../src/bootstrap-emacs[0x8137efc]
../src/bootstrap-emacs[0x811ff9a]
../src/bootstrap-emacs[0x8136ace]
../src/bootstrap-emacs[0x8136c1b]
../src/bootstrap-emacs[0x8136cac]
/lib/i386-gnu/libc.so.0.3(+0x3f9d2)[0x2cf99d2]
/bin/bash: line 1: 10176 Aborted                 EMACSLOADPATH=
'../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp --eval '(setq
load-prefer-newer t)' -f batch-byte-compile emacs-lisp/macroexp.el

> Instead, try building an official 25.1 release tarball, then invoke
> temacs built there, and see if it works.

Will try the release 25.1 tarball next: Last time I built from an upstream
tarball it did succeed the first time and failed the second.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Fri, 11 Nov 2016 10:50:16 +0100
> 
> I did build from today's git. After setting libsystemd to off
> OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
> the build was successful: all three built executables: temacs, bootstrap-emacs,
> emacs works fine.
> 
> Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:

So you are saying that turning off libsystemd and NOT forcing
SYSTEM_MALLOC allows you to build Emacs successfully?

Also, do you understand how does libsystemd affect this?

> > Instead, try building an official 25.1 release tarball, then invoke
> > temacs built there, and see if it works.
> 
> Will try the release 25.1 tarball next: Last time I built from an upstream
> tarball it did succeed the first time and failed the second.

"The second time" here meaning what? that you modified some file and
ran "make" again?  Or does it mean something else?

Thanks.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 12:06 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> > Date: Fri, 11 Nov 2016 10:50:16 +0100
> > 
> > I did build from today's git. After setting libsystemd to off
> > OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
> > the build was successful: all three built executables: temacs, bootstrap-
> > emacs,
> > emacs works fine.
> > 
> > Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:
> So you are saying that turning off libsystemd and NOT forcing
> SYSTEM_MALLOC allows you to build Emacs successfully?
> 
> Also, do you understand how does libsystemd affect this?

No, I don't. But I know that GNU/Hurd has no support for anything systemd-
related at all. And the build with it enabled failed miserably.

> > > Instead, try building an official 25.1 release tarball, then invoke
> > > temacs built there, and see if it works.
> > Will try the release 25.1 tarball next: Last time I built from an upstream
> > tarball it did succeed the first time and failed the second.
> "The second time" here meaning what? that you modified some file and
> ran "make" again?  Or does it mean something else?

I've now built the tarball and that went OK. Also after make distclean;
configure; make all was fine. 

However rebuilding the git from today crashed the box hard: Console output:
/hurd/crash: src/bootstrap-emacs -Q(1172), signal {no:11, code:1, error:1},
exception {1, code:1, subcode:3496312}, PCs: {0x818d803, 0x51db97c}, Killing
task. <and four more similar entries>. This might be a Hud bug or memory
exhaustion.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Fri, 11 Nov 2016 11:32:30 +0100
> 
> On Fri, 2016-11-11 at 12:06 +0200, Eli Zaretskii wrote:
> > > 
> > > From: Svante Signell <svante.signell@gmail.com>
> > > Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> > > Date: Fri, 11 Nov 2016 10:50:16 +0100
> > > 
> > > I did build from today's git. After setting libsystemd to off
> > > OPTION_DEFAULT_OFF([libsystemd],[don't compile with libsystemd support])
> > > the build was successful: all three built executables: temacs, bootstrap-
> > > emacs,
> > > emacs works fine.
> > > 
> > > Forcing usage of SYSTEM_MALLOC fails with bootstrap-emacs:
> > So you are saying that turning off libsystemd and NOT forcing
> > SYSTEM_MALLOC allows you to build Emacs successfully?
> > 
> > Also, do you understand how does libsystemd affect this?
> 
> No, I don't. But I know that GNU/Hurd has no support for anything systemd-
> related at all. And the build with it enabled failed miserably.
> 
> > > > Instead, try building an official 25.1 release tarball, then invoke
> > > > temacs built there, and see if it works.
> > > Will try the release 25.1 tarball next: Last time I built from an upstream
> > > tarball it did succeed the first time and failed the second.
> > "The second time" here meaning what? that you modified some file and
> > ran "make" again?  Or does it mean something else?
> 
> I've now built the tarball and that went OK. Also after make distclean;
> configure; make all was fine. 
> 
> However rebuilding the git from today crashed the box hard: Console output:
> /hurd/crash: src/bootstrap-emacs -Q(1172), signal {no:11, code:1, error:1},
> exception {1, code:1, subcode:3496312}, PCs: {0x818d803, 0x51db97c}, Killing
> task. <and four more similar entries>. This might be a Hud bug or memory
> exhaustion.

Thanks, so what remains to be addressed in this bug report, before we
declare it done?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Fri, 11 Nov 2016 11:32:30 +0100
> 
> > Also, do you understand how does libsystemd affect this?
> 
> No, I don't. But I know that GNU/Hurd has no support for anything systemd-
> related at all. And the build with it enabled failed miserably.

Evidently, you do have libsystemd on your machine, because the
configure script detects its presence (by calling pkg-config), and
also the link step of the build succeeds to link against libsystemd.
What is the story here?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 12:59 +0200, Eli Zaretskii wrote:

> > However rebuilding the git from today crashed the box hard: Console output:
> > /hurd/crash: src/bootstrap-emacs -Q(1172), signal {no:11, code:1, error:1},
> > exception {1, code:1, subcode:3496312}, PCs: {0x818d803, 0x51db97c}, Killing
> > task. <and four more similar entries>. This might be a Hurd bug or memory
> > exhaustion.
> Thanks, so what remains to be addressed in this bug report, before we
> declare it done?

Well, rebooting, checking disks and building again freeze the box hard, no
successful build this time :(
Dumping under the name emacs
5883168 of 16777216 static heap bytes used
<box freeze>

This is the behaviour for every build since 24.5. So I don't think this bug can
be closed. There must be ways to build emacs without crashing the gnumach
kernel/ext2 filesystem!

Are you going to remove the obscure unxec stuff anytime soon? And use system
malloc functions from glibc instead of home-brewn versions?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 13:03 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> > Date: Fri, 11 Nov 2016 11:32:30 +0100
> > 
> > > 
> > > Also, do you understand how does libsystemd affect this?
> > No, I don't. But I know that GNU/Hurd has no support for anything systemd-
> > related at all. And the build with it enabled failed miserably.
> Evidently, you do have libsystemd on your machine, because the
> configure script detects its presence (by calling pkg-config), and
> also the link step of the build succeeds to link against libsystemd.
> What is the story here?

There is a dummy systemd development library installed, to enable build of some
packages:
ii  libsystemd-dev    222-1         hurd-i386     Dummy systemd utility library

This is a Debian construct.

#> dpkg -s libsystemd-dev
Package: libsystemd-dev
Status: install ok installed
Priority: extra
Section: oldlibs
Installed-Size: 27
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.deb
ian.org>
Architecture: hurd-i386
Source: libsystemd-dummy
Version: 222-1
Description: Dummy systemd utility library
 This package provides a dummy version of the libsystemd-dev
 package for the architectures which lack an implementation of the library.

#> dpkg -L libsystemd-dev
/.
/usr
/usr/include
/usr/include/systemd
/usr/include/systemd/sd-daemon.h
/usr/lib
/usr/lib/pkgconfig
/usr/lib/pkgconfig/libsystemd.pc
/usr/share
/usr/share/doc
/usr/share/doc/libsystemd-dev
/usr/share/doc/libsystemd-dev/copyright
/usr/share/doc/libsystemd-dev/changelog.Debian.gz
/usr/lib/pkgconfig/libsystemd-daemon.pc

Maybe you should have some better way of detecting libsystemd presence?
man pkg-config:
pkg-config retrieves information about packages from special metadata files.
These files are named after the package, and has a .pc extension.

On the GNU/Hurd system no libsystemd* library exist!

See above:
/usr/lib/pkgconfig/libsystemd.pc
/usr/lib/pkgconfig/libsystemd-daemon.pc

I don't really understand why a GNU project adds support for the systemd
disaster. Take a look at Guix, they chose another way out. Additionally we have
Devuan and their downstream releases.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Fri, 11 Nov 2016 12:18:33 +0100
> 
> Well, rebooting, checking disks and building again freeze the box hard, no
> successful build this time :(
> Dumping under the name emacs
> 5883168 of 16777216 static heap bytes used
> <box freeze>

Does /var/log/messages (or wherever that is on Hurd) have anything
interesting at that point?

> Are you going to remove the obscure unxec stuff anytime soon? And use system
> malloc functions from glibc instead of home-brewn versions?

We are not yet sure this is due to unexec.  That's why I asked you to
try to run temacs.  If temacs runs well and has no issues, then yes,
unexec is the most likely culprit.

I do wonder what happened in 24.5 that Emacs became unbuildable on
Hurd.  Can you still build 24.4 on your current system?  If so,
perhaps look at the diffs between unexelf.c in 24.4 and the current
version, and try to figure out what changes there cause the failure on
Hurd.

Thanks.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Fri, 11 Nov 2016 12:33:25 +0100
> 
> > Evidently, you do have libsystemd on your machine, because the
> > configure script detects its presence (by calling pkg-config), and
> > also the link step of the build succeeds to link against libsystemd.
> > What is the story here?
> 
> There is a dummy systemd development library installed, to enable build of some
> packages:
> ii  libsystemd-dev    222-1         hurd-i386     Dummy systemd utility library
> 
> This is a Debian construct.
> 
> #> dpkg -s libsystemd-dev
> Package: libsystemd-dev
> Status: install ok installed
> Priority: extra
> Section: oldlibs
> Installed-Size: 27
> Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.deb
> ian.org>
> Architecture: hurd-i386
> Source: libsystemd-dummy
> Version: 222-1
> Description: Dummy systemd utility library
>  This package provides a dummy version of the libsystemd-dev
>  package for the architectures which lack an implementation of the library.
> 
> #> dpkg -L libsystemd-dev
> /.
> /usr
> /usr/include
> /usr/include/systemd
> /usr/include/systemd/sd-daemon.h
> /usr/lib
> /usr/lib/pkgconfig
> /usr/lib/pkgconfig/libsystemd.pc
> /usr/share
> /usr/share/doc
> /usr/share/doc/libsystemd-dev
> /usr/share/doc/libsystemd-dev/copyright
> /usr/share/doc/libsystemd-dev/changelog.Debian.gz
> /usr/lib/pkgconfig/libsystemd-daemon.pc
> 
> Maybe you should have some better way of detecting libsystemd presence?

If you can suggest a way to detect this dummy version, we can
incorporate it in the configure script.

> I don't really understand why a GNU project adds support for the systemd
> disaster.

One man's disaster is another man's most wanted feature.  The world is
divided wrt systemd, and Emacs as a project doesn't have a firm stand
about that.

Thanks.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-11-11 at 16:03 +0200, Eli Zaretskii wrote:
> > 
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> > Date: Fri, 11 Nov 2016 12:18:33 +0100
> > 
> > Well, rebooting, checking disks and building again freeze the box hard, no
> > successful build this time :(
> > Dumping under the name emacs
> > 5883168 of 16777216 static heap bytes used
> > <box freeze>
> Does /var/log/messages (or wherever that is on Hurd) have anything
> interesting at that point?

Dunno, I'll take a look next time it happens. Probably not since nothing is even
written on the console.

> > Are you going to remove the obscure unxec stuff anytime soon? And use system
> > malloc functions from glibc instead of home-brewn versions?
> We are not yet sure this is due to unexec.  That's why I asked you to
> try to run temacs.  If temacs runs well and has no issues, then yes,
> unexec is the most likely culprit.
> 
> I do wonder what happened in 24.5 that Emacs became unbuildable on
> Hurd.  Can you still build 24.4 on your current system?  If so,
> perhaps look at the diffs between unexelf.c in 24.4 and the current
> version, and try to figure out what changes there cause the failure on
> Hurd.

Now even older versions FTBFS, like the one that built earlier: 2.24-5. It might
have to do with libc versions:
emacs 2.24-5 was successfully built with glibc 2.19
emacs 2.24-6 was FTBFS with glibc 2.22
Now we are at glibc 2.24.

All older versions I've tried gets Killed when dumping temacs.
e.g. emacs24.5-5:
/bin/bash: line 7: 29388 Killed                  ./temacs --batch --load loadup
bootstrap

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Fri, 11 Nov 2016 16:04:45 +0100
> 
> > I do wonder what happened in 24.5 that Emacs became unbuildable on
> > Hurd.  Can you still build 24.4 on your current system?  If so,
> > perhaps look at the diffs between unexelf.c in 24.4 and the current
> > version, and try to figure out what changes there cause the failure on
> > Hurd.
> 
> Now even older versions FTBFS, like the one that built earlier: 2.24-5. It might
> have to do with libc versions:
> emacs 2.24-5 was successfully built with glibc 2.19
> emacs 2.24-6 was FTBFS with glibc 2.22
> Now we are at glibc 2.24.
> 
> All older versions I've tried gets Killed when dumping temacs.
> e.g. emacs24.5-5:
> /bin/bash: line 7: 29388 Killed                  ./temacs --batch --load loadup
> bootstrap

That's what I thought.

Can you compare src/config.h from the old builds and the current ones?

Any idea what change(s) in glibc caused this?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

Svante Signell wrote:
> Maybe you should have some better way of detecting libsystemd presence?

The Emacs way of using systemd should work with the dummy. libsystemd-dummy 
should define a dummy function sd_listen_fds that always returns 0, and this 
should cause Emacs to avoid using systemd. Evidently this is not working for 
you; can you investigate why? E.g., can you run Emacs under a debugger and 
verify that sd_listen_fds is the only libsystemd function it calls?

As far as the memory problems go, it appears that sometimes they happen and 
sometimes they don't, and we don't really know why. Although it could well be 
unexec, it could well be something else too. It's frustrating.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> Date: Fri, 11 Nov 2016 17:33:20 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> 
> > Now even older versions FTBFS, like the one that built earlier: 2.24-5. It might
> > have to do with libc versions:
> > emacs 2.24-5 was successfully built with glibc 2.19
> > emacs 2.24-6 was FTBFS with glibc 2.22
> > Now we are at glibc 2.24.
> > 
> > All older versions I've tried gets Killed when dumping temacs.
> > e.g. emacs24.5-5:
> > /bin/bash: line 7: 29388 Killed                  ./temacs --batch --load loadup
> > bootstrap
> 
> That's what I thought.
> 
> Can you compare src/config.h from the old builds and the current ones?
> 
> Any idea what change(s) in glibc caused this?

Ping!  Any news on this?

Emacs 25.2 will begin pretest soon, and it would be nice to at least
know the situation on Hurd with it, if not have a solution.

TIA

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Wed, 2016-11-02 at 16:51 +0100, Svante Signell wrote:
> On Wed, 2016-11-02 at 17:39 +0200, Eli Zaretskii wrote:
> > > 
> > > From: Svante Signell <svante.signell@gmail.com>
> > > Date: Wed, 02 Nov 2016 15:16:54 +0100
> > > 
> > > First time I compiled emacs 25.1 from upstream it passed, second time not.
> > > Compiling Debian versions almost always fail. Moslty the build fails with
> > > temacs
> > > failing to execute: Killed. In my opionion it's a real loss not to gave a
> > > modern
> > > version of emacs25 available for use in GNU/Hurd (not everybody use vi).
> > > 
> > > Do anybody of you have an idea on how to solve this problem?
> > My suggestion is to run the failing temacs command line under GDB and
> > see where it crashes.
> 
> Hi, attached is a traceback from gdb. Edited to remove thousands of loops, as
> indicated in that file.

<follow ups to the bug #24857 showed an inability to allocate memory>

> > The best way to communicate this information is to file a bug report,
> > using "M-x report-emacs-bug RET" (in some version of Emacs you have
> > that is operable; if not, just email the details to
> > bug-gnu-emacs@gnu.org).
> 
> A bug was already filed by
> Paul Eggert, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24857

Hi, again. Irrespective of the discussion ongoing of a C or Lisp implementation
of dump, I'd like to try the patch supplied by Daniel Colascione. Does it still
apply without problems to the main repo git://git.sv.gnu.org/emacs.git?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

On 12/02/2016 02:35 AM, Svante Signell wrote:
> Irrespective of the discussion ongoing of a C or Lisp implementation
> of dump, I'd like to try the patch supplied by Daniel Colascione. Does it still
> apply without problems to the main repo git://git.sv.gnu.org/emacs.git?

I doubt it. However, Daniel indicated here:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html

that he would create a branch for that patch this weekend, and I suggest 
trying that branch. As a Savannah upgrade is in progress, you may have 
to wait before it's available; see:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Fri, 2016-12-02 at 16:02 -0800, Paul Eggert wrote:
> On 12/02/2016 02:35 AM, Svante Signell wrote:
> > Irrespective of the discussion ongoing of a C or Lisp implementation
> > of dump, I'd like to try the patch supplied by Daniel Colascione. Does it
> > still
> > apply without problems to the main repo git://git.sv.gnu.org/emacs.git?
> 
> I doubt it. However, Daniel indicated here:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html
> 
> that he would create a branch for that patch this weekend, and I suggest 
> trying that branch. As a Savannah upgrade is in progress, you may have 
> to wait before it's available; see:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html

Daniel,

What is the status of your branch containing the portable dumper? Nothing so far
in http://git.savannah.gnu.org/cgit/emacs.git
Emacs still FTBFS miserably on GNU/Hurd, both old (previously building) versions
as new ones. The latest successful build was for Debian version 2.24+1-5, in Nov
28 2015, more than a year ago :(

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Daniel Colascione]

On 12/07/2016 02:40 PM, Svante Signell wrote:
> On Fri, 2016-12-02 at 16:02 -0800, Paul Eggert wrote:
>> On 12/02/2016 02:35 AM, Svante Signell wrote:
>>> Irrespective of the discussion ongoing of a C or Lisp implementation
>>> of dump, I'd like to try the patch supplied by Daniel Colascione. Does it
>>> still
>>> apply without problems to the main repo git://git.sv.gnu.org/emacs.git?
>>
>> I doubt it. However, Daniel indicated here:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00081.html
>>
>> that he would create a branch for that patch this weekend, and I suggest
>> trying that branch. As a Savannah upgrade is in progress, you may have
>> to wait before it's available; see:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00095.html
>
> Daniel,
>
> What is the status of your branch containing the portable dumper? Nothing so far
> in http://git.savannah.gnu.org/cgit/emacs.git
> Emacs still FTBFS miserably on GNU/Hurd, both old (previously building) versions
> as new ones. The latest successful build was for Debian version 2.24+1-5, in Nov
> 28 2015, more than a year ago :(
>

Sorry for the delay --- I've been a bit held up in some personal 
business. I recently fixed some bugs in the unexec-mode-in-pdumper-build 
case, and I want to get end-to-end installation (loading the dump after 
'make install') working before I push the branch. Shouldn't be too long.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

The last message I see from you on this bug report <http://bugs.gnu.org/24857> 
is that you'd try something and report back. Did that ever happen? Also, could 
you try the latest Emacs master instead? That would be more helpful than trying 
to build old versions.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

unblock 24655 by 24857
thanks

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Fri, 14 Jul 2017 05:21:44 -0700
> Cc: 24857@debbugs.gnu.org
> 
> The last message I see from you on this bug report <http://bugs.gnu.org/24857> 
> is that you'd try something and report back. Did that ever happen? Also, could 
> you try the latest Emacs master instead? That would be more helpful than trying 
> to build old versions.

And another 1.5 month later with no responses, I conclude that we
shouldn't block our releases due to this issue.

Thanks.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Sat, 2017-09-02 at 16:45 +0300, Eli Zaretskii wrote:
> unblock 24655 by 24857
> thanks
> 
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > Date: Fri, 14 Jul 2017 05:21:44 -0700
> > Cc: 24857@debbugs.gnu.org
> > 
> > The last message I see from you on this bug report
> > <http://bugs.gnu.org/24857> is that you'd try something and report
> > back. Did that ever happen? Also, could you try the latest Emacs
> > master instead? That would be more helpful than trying 
> > to build old versions.
> 
> And another 1.5 month later with no responses, I conclude that we
> shouldn't block our releases due to this issue.

Sorry for not responding so far. I tried the rebuild and it failed
then. After that emacs25 sometimes succeeds and sometimes fails to
build on Hurd buildds. Mostly fails unfortunately.
Examples:
 25.1+1-1: fails
 25.1+1-2: fails
 25.1+1-3: succeeds
 25.2+1-2: succeeds
 25.2+1-5: buildd hangs

So the problem persists, even if the Debian package build is now
different. I don't expect that a build from Emacs master would succeed,
if built the Debian way with three targets: build-nox, build-x and
build-lucid. When I tried with the master sources the largest problem
was when enabling X. Still the same problems with Emacs
internal/external malloc-related code exist.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: 24857@debbugs.gnu.org
> Date: Sat, 02 Sep 2017 16:10:18 +0200
> 
> Sorry for not responding so far. I tried the rebuild and it failed
> then. After that emacs25 sometimes succeeds and sometimes fails to
> build on Hurd buildds. Mostly fails unfortunately.
> Examples:
>  25.1+1-1: fails
>  25.1+1-2: fails
>  25.1+1-3: succeeds
>  25.2+1-2: succeeds
>  25.2+1-5: buildd hangs
> 
> So the problem persists, even if the Debian package build is now
> different. I don't expect that a build from Emacs master would succeed,
> if built the Debian way with three targets: build-nox, build-x and
> build-lucid. When I tried with the master sources the largest problem
> was when enabling X. Still the same problems with Emacs
> internal/external malloc-related code exist.

Please do try the master branch, as the memory allocation code has
changed considerably there.

Thanks.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Svante Signell]

On Sat, 2017-09-02 at 17:27 +0300, Eli Zaretskii wrote:
> > From: Svante Signell <svante.signell@gmail.com>
> > Cc: 24857@debbugs.gnu.org
> > Date: Sat, 02 Sep 2017 16:10:18 +0200
> > 
> > Sorry for not responding so far. I tried the rebuild and it failed
> > then. After that emacs25 sometimes succeeds and sometimes fails to
> > build on Hurd buildds. Mostly fails unfortunately.
> > Examples:
> >  25.1+1-1: fails
> >  25.1+1-2: fails
> >  25.1+1-3: succeeds
> >  25.2+1-2: succeeds
> >  25.2+1-5: buildd hangs
> > 
> > So the problem persists, even if the Debian package build is now
> > different. I don't expect that a build from Emacs master would
> > succeed,
> > if built the Debian way with three targets: build-nox, build-x and
> > build-lucid. When I tried with the master sources the largest
> > problem
> > was when enabling X. Still the same problems with Emacs
> > internal/external malloc-related code exist.
> 
> Please do try the master branch, as the memory allocation code has
> changed considerably there.

Do I issue git clone etc?

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Eli Zaretskii]

> From: Svante Signell <svante.signell@gmail.com>
> Cc: eggert@cs.ucla.edu, 24857@debbugs.gnu.org
> Date: Sat, 02 Sep 2017 16:43:20 +0200
> 
> > Please do try the master branch, as the memory allocation code has
> > changed considerably there.
> 
> Do I issue git clone etc?

Yes.  The instructions are here:

  https://savannah.gnu.org/git/?group=emacs

Thanks.

bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd

[Paul Eggert]

Svante Signell wrote:
> Do I issue git clone etc?

Yes, I suggest following the instructions in CONTRIBUTE.

http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE