* emacs24/25 FTBFS since a long time on GNU/Hurd @ 2016-11-02 14:16 Svante Signell 2016-11-02 15:23 ` Paul Eggert 2016-11-02 15:39 ` Eli Zaretskii 0 siblings, 2 replies; 11+ messages in thread From: Svante Signell @ 2016-11-02 14:16 UTC (permalink / raw) To: emacs-devel Hello, I'm not subscribed to emacs-devel, but hope to get this mail through anyway. 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 :) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 14:16 emacs24/25 FTBFS since a long time on GNU/Hurd Svante Signell @ 2016-11-02 15:23 ` Paul Eggert 2016-11-02 15:39 ` Eli Zaretskii 1 sibling, 0 replies; 11+ messages in thread From: Paul Eggert @ 2016-11-02 15:23 UTC (permalink / raw) To: svante.signell; +Cc: emacs-devel I created Bug#24857 for this and plan to follow up there <http://bugs.gnu.org/24857>. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 14:16 emacs24/25 FTBFS since a long time on GNU/Hurd Svante Signell 2016-11-02 15:23 ` Paul Eggert @ 2016-11-02 15:39 ` Eli Zaretskii 2016-11-02 15:51 ` Svante Signell 2016-11-02 16:43 ` bug#24857: Fwd: " Paul Eggert 1 sibling, 2 replies; 11+ messages in thread From: Eli Zaretskii @ 2016-11-02 15:39 UTC (permalink / raw) To: svante.signell; +Cc: emacs-devel > 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). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 15:39 ` Eli Zaretskii @ 2016-11-02 15:51 ` Svante Signell 2016-11-02 16:44 ` bug#24857: Fwd: " Paul Eggert ` (2 more replies) 2016-11-02 16:43 ` bug#24857: Fwd: " Paul Eggert 1 sibling, 3 replies; 11+ messages in thread From: Svante Signell @ 2016-11-02 15:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1095 bytes --] 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?) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#24857: Fwd: Re: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 15:51 ` Svante Signell @ 2016-11-02 16:44 ` Paul Eggert 2016-12-02 10:35 ` bug#24857: " Svante Signell 2016-12-02 10:35 ` Svante Signell 2 siblings, 0 replies; 11+ messages in thread From: Paul Eggert @ 2016-11-02 16:44 UTC (permalink / raw) To: 24857 [-- 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?) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 15:51 ` Svante Signell 2016-11-02 16:44 ` bug#24857: Fwd: " Paul Eggert @ 2016-12-02 10:35 ` Svante Signell 2016-12-02 10:35 ` Svante Signell 2 siblings, 0 replies; 11+ messages in thread From: Svante Signell @ 2016-12-02 10:35 UTC (permalink / raw) To: emacs-devel; +Cc: 24857 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 15:51 ` Svante Signell 2016-11-02 16:44 ` bug#24857: Fwd: " Paul Eggert 2016-12-02 10:35 ` bug#24857: " Svante Signell @ 2016-12-02 10:35 ` Svante Signell 2016-12-03 0:02 ` bug#24857: " Paul Eggert 2 siblings, 1 reply; 11+ messages in thread From: Svante Signell @ 2016-12-02 10:35 UTC (permalink / raw) To: emacs-devel; +Cc: 24857 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-12-02 10:35 ` Svante Signell @ 2016-12-03 0:02 ` Paul Eggert 2016-12-07 22:40 ` Svante Signell 0 siblings, 1 reply; 11+ messages in thread From: Paul Eggert @ 2016-12-03 0:02 UTC (permalink / raw) To: svante.signell, emacs-devel; +Cc: 24857 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-12-03 0:02 ` bug#24857: " Paul Eggert @ 2016-12-07 22:40 ` Svante Signell 2016-12-08 1:15 ` Daniel Colascione 0 siblings, 1 reply; 11+ messages in thread From: Svante Signell @ 2016-12-07 22:40 UTC (permalink / raw) To: Paul Eggert, emacs-devel, dancol; +Cc: 24857 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 :( ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#24857: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-12-07 22:40 ` Svante Signell @ 2016-12-08 1:15 ` Daniel Colascione 0 siblings, 0 replies; 11+ messages in thread From: Daniel Colascione @ 2016-12-08 1:15 UTC (permalink / raw) To: svante.signell, Paul Eggert, emacs-devel; +Cc: 24857 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#24857: Fwd: Re: emacs24/25 FTBFS since a long time on GNU/Hurd 2016-11-02 15:39 ` Eli Zaretskii 2016-11-02 15:51 ` Svante Signell @ 2016-11-02 16:43 ` Paul Eggert 1 sibling, 0 replies; 11+ messages in thread From: Paul Eggert @ 2016-11-02 16:43 UTC (permalink / raw) To: 24857 -------- 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). ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2016-12-08 1:15 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-02 14:16 emacs24/25 FTBFS since a long time on GNU/Hurd Svante Signell 2016-11-02 15:23 ` Paul Eggert 2016-11-02 15:39 ` Eli Zaretskii 2016-11-02 15:51 ` Svante Signell 2016-11-02 16:44 ` bug#24857: Fwd: " Paul Eggert 2016-12-02 10:35 ` bug#24857: " Svante Signell 2016-12-02 10:35 ` Svante Signell 2016-12-03 0:02 ` bug#24857: " Paul Eggert 2016-12-07 22:40 ` Svante Signell 2016-12-08 1:15 ` Daniel Colascione 2016-11-02 16:43 ` bug#24857: Fwd: " Paul Eggert
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.