* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
@ 2017-07-17 15:29 ` Noam Postavsky
2017-07-17 16:10 ` Keith David Bershatsky
` (11 subsequent siblings)
12 siblings, 0 replies; 39+ messages in thread
From: Noam Postavsky @ 2017-07-17 15:29 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
On Mon, Jul 17, 2017 at 11:18 AM, Keith David Bershatsky
<esq@lawlist.com> wrote:
> I am unable to build Emacs from the master branch on OSX 10.6.8 with Eshell, which is what I have used for several years. It just stops/freezes when it gets to: "ELC org/org-timer.elc". I am still able to successfully build earlier versions of Emacs master branch from last year -- I am unsure what specific day the builds stopped working.
Can you clarify if it works outside eshell?
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
2017-07-17 15:29 ` Noam Postavsky
@ 2017-07-17 16:10 ` Keith David Bershatsky
2017-07-17 16:38 ` Noam Postavsky
2017-07-17 18:05 ` Keith David Bershatsky
` (10 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-07-17 16:10 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 27736
> Can you clarify if it works outside eshell?
Thank you for taking a look at this bug report. I just tried building master branch from Terminal.app on OSX 10.6.8 -- without using Emacs -- and I had the same results. I.e., it stops when it gets to "ELC org/org-timer.elc". There is no error message.
Last login: Mon Jul 17 07:02:29 on console
server:emacs HOME$ PATH=/Users/HOME/.0.data/.0.emacs/.0.build/bin:/usr/bin:/bin:/usr/sbin:/sbin
server:emacs HOME$ ./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Building aclocal.m4 ...
Running 'autoreconf -fi -I m4' ...
./autogen.sh: line 274: git: command not found
./autogen.sh: line 274: git: command not found
./autogen.sh: line 274: git: command not found
./autogen.sh: line 274: git: command not found
./autogen.sh: line 274: git: command not found
./autogen.sh: line 274: git: command not found
You can now run './autogen.sh git'.
server:emacs HOME$ ./configure \
> --with-ns \
> --enable-checking='glyphs' \
> --without-compress-install \
> --without-makeinfo \
> --with-gnutls=no \
> --with-mailutils
checking for xcrun... xcrun
checking for make... yes
checking for GNU Make... make
checking build system type... x86_64-apple-darwin10.8.0
checking host system type... x86_64-apple-darwin10.8.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... unsupported
checking for gcc option to enable C99 features... -std=gnu99
checking for ar... ar
checking whether gcc -std=gnu99 and cc understand -c and -o together... yes
checking for putenv... yes
checking for sbrk... yes
checking for fchmod... yes
checking for readlinkat... no
checking for explicit_bzero... no
checking for faccessat... no
checking for fcntl... yes
checking for fdopendir... no
checking for fstatat... no
checking for fsync... yes
checking for gettimeofday... yes
checking for nanotime... no
checking for lstat... yes
checking for mkostemp... no
checking for tzset... yes
checking for pipe2... no
checking for pselect... yes
checking for readlink... yes
checking for strtoimax... yes
checking for symlink... yes
checking for localtime_r... yes
checking for timegm... yes
checking for futimes... yes
checking for futimesat... no
checking for futimens... no
checking for utimensat... no
checking for lutimes... yes
checking for getdtablesize... yes
checking for secure_getenv... no
checking for getuid... yes
checking for geteuid... yes
checking for getgid... yes
checking for getegid... yes
checking how to run the C preprocessor... gcc -std=gnu99 -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for Minix Amsterdam compiler... no
checking for ranlib... ranlib
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking whether gcc -std=gnu99 accepts -g3 -O2... yes
checking whether the compiler is clang... no
checking whether C compiler handles -Werror -Wunknown-warning-option... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works for files in the same directory... yes
checking for install-info... /usr/bin/install-info
checking for gzip... /usr/bin/gzip
checking for 'find' args to delete a file... -delete
checking for -znocombreloc... no
checking whether addresses are sanitized... no
checking for library containing sqrt... none required
checking for pkg-config... no
checking for machine/soundcard.h... no
checking for sys/soundcard.h... no
checking for soundcard.h... no
checking for mmsystem.h... no
checking for _oss_ioctl in -lossaudio... no
checking for ALSA... no
checking for linux/fs.h... no
checking for malloc.h... no
checking for sys/systeminfo.h... no
checking for sys/sysinfo.h... no
checking for coff.h... no
checking for pty.h... no
checking for sys/resource.h... yes
checking for sys/utsname.h... yes
checking for pwd.h... yes
checking for utmp.h... yes
checking for util.h... yes
checking for sys/prctl.h... no
checking for sys/socket.h... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for pthread.h... yes
checking for malloc/malloc.h... yes
checking for sys/un.h... yes
checking for dirent.h... yes
checking for execinfo.h... yes
checking for stdio_ext.h... no
checking for getopt.h... yes
checking for sys/cdefs.h... yes
checking for sys/time.h... yes
checking for limits.h... yes
checking for wchar.h... yes
checking for stdint.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for sys/select.h... yes
checking for sys/stat.h... (cached) yes
checking for ADDR_NO_RANDOMIZE... no
checking for term.h... yes
checking whether time.h and sys/time.h may both be included... yes
checking whether sys_siglist is declared... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking for net/if.h... yes
checking for ifaddrs.h... yes
checking for net/if_dl.h... yes
checking for struct ifreq.ifr_flags... yes
checking for struct ifreq.ifr_hwaddr... no
checking for struct ifreq.ifr_netmask... no
checking for struct ifreq.ifr_broadaddr... yes
checking for struct ifreq.ifr_addr... yes
checking for struct ifreq.ifr_addr.sa_len... yes
checking whether gcc understands -MMD -MF... yes
checking for long file names... yes
checking for X... libraries /usr/X11/lib, headers
checking AppKit/AppKit.h usability... yes
checking AppKit/AppKit.h presence... yes
checking for AppKit/AppKit.h... yes
checking for Mac OS X 10.6 or newer... yes
checking for gcc... gcc
checking whether we are using the GNU Objective C compiler... yes
checking whether gcc accepts -g... yes
checking if the Objective C compiler supports instancetype... no
checking whether malloc is Doug Lea style... no
checking for getpagesize... yes
checking for working mmap... yes
checking for main in -lXbsd... no
checking for pthread library... none needed
checking for thread support... yes
checking for RSVG... no
checking for IMAGEMAGICK... no
checking for getaddrinfo_a in -lanl... no
checking for DBUS... no
checking for lgetfilecon in -lselinux... no
checking for LIBSYSTEMD... no
checking sys/inotify.h usability... no
checking sys/inotify.h presence... no
checking for sys/inotify.h... no
checking for KQUEUE... no
checking for library containing kqueue... none required
checking for jpeglib 6b or later... no
checking for library containing inflateEnd... -lz
checking gpm.h usability... no
checking gpm.h presence... no
checking for gpm.h... no
checking for LIBXML2... no
checking libxml/HTMLparser.h usability... yes
checking libxml/HTMLparser.h presence... yes
checking for libxml/HTMLparser.h... yes
checking whether HTML_PARSE_RECOVER is declared... yes
checking for htmlReadMemory in -lxml2... yes
checking for accept4... no
checking for fchdir... yes
checking for gethostname... yes
checking for getrusage... yes
checking for get_current_dir_name... no
checking for lrand48... yes
checking for random... yes
checking for rint... yes
checking for trunc... yes
checking for select... yes
checking for getpagesize... (cached) yes
checking for setlocale... yes
checking for newlocale... yes
checking for getrlimit... yes
checking for setrlimit... yes
checking for shutdown... yes
checking for pthread_sigmask... (cached) yes
checking for strsignal... yes
checking for setitimer... yes
checking for sendto... yes
checking for recvfrom... yes
checking for getsockname... yes
checking for getifaddrs... yes
checking for freeifaddrs... yes
checking for gai_strerror... yes
checking for sync... yes
checking for getpwent... yes
checking for endpwent... yes
checking for getgrent... yes
checking for endgrent... yes
checking for cfmakeraw... yes
checking for cfsetspeed... yes
checking for __executable_start... no
checking for log2... yes
checking for prctl... no
checking for aligned_alloc... no
checking for posix_memalign... yes
checking whether aligned_alloc is declared... no
checking for __builtin_unwind_init... yes
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for grantpt... yes
checking for getpt... no
checking for posix_openpt... yes
checking for library containing tputs... -lncurses
checking for timerfd interface... no
checking whether signals can be handled on alternate stack... yes
checking valgrind/valgrind.h usability... no
checking valgrind/valgrind.h presence... no
checking for valgrind/valgrind.h... no
checking for struct unipair.unicode... no
checking for socket... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking for pid_t... yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking for snprintf... yes
checking whether GLib is linked in... no
checking for nl_langinfo and CODESET... yes
checking for mbstate_t... yes
checking for _setjmp... yes
checking for sigsetjmp... yes
checking for usable FIONREAD... yes
checking for usable SIGIO... yes
checking for struct alignment... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for unsigned long long int... yes
checking whether byte ordering is bigendian... no
checking whether the preprocessor supports include_next... yes
checking whether system header files limit the line length... no
checking whether strtold conforms to C99... yes
checking if environ is properly declared... no
checking for complete errno.h... no
checking for EMULTIHOP value... yes
checking for ENOLINK value... yes
checking for EOVERFLOW value... yes
checking for mode_t... yes
checking whether fdatasync is declared... no
checking for st_dm_mode in struct stat... no
checking whether strmode is declared... yes
checking whether lstat correctly handles trailing slash... no
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for getopt.h... (cached) yes
checking for getopt_long_only... yes
checking whether getopt is POSIX compatible... no
checking for C/C++ restrict keyword... no
checking for struct timeval... yes
checking for wide-enough struct timeval.tv_sec member... yes
checking whether limits.h has ULLONG_WIDTH etc.... no
checking for long long int... yes
checking whether stdint.h conforms to C99... no
checking sys/inttypes.h usability... no
checking sys/inttypes.h presence... no
checking for sys/inttypes.h... no
checking sys/bitypes.h usability... no
checking sys/bitypes.h presence... no
checking for sys/bitypes.h... no
checking for bit size of ptrdiff_t... 64
checking for bit size of size_t... 64
checking for bit size of sig_atomic_t... 32
checking for bit size of wchar_t... 32
checking for bit size of wint_t... 32
checking whether sig_atomic_t is signed... yes
checking whether wchar_t is signed... yes
checking whether wint_t is signed... yes
checking for ptrdiff_t integer literal suffix... l
checking for size_t integer literal suffix... ul
checking for sig_atomic_t integer literal suffix...
checking for wchar_t integer literal suffix...
checking for wint_t integer literal suffix...
checking whether memrchr is declared... no
checking whether <limits.h> defines MIN and MAX... no
checking whether <sys/param.h> defines MIN and MAX... yes
checking whether time_t is signed... yes
checking whether alarm is declared... yes
checking for working mktime... no
checking whether <sys/select.h> is self-contained... yes
checking for sigset_t... yes
checking for wchar_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking for struct tm.tm_zone... yes
checking for struct tm.tm_gmtoff... yes
checking whether strtoimax is declared... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking whether stat file-mode macros are broken... no
checking for struct timespec in <time.h>... yes
checking whether clearerr_unlocked is declared... yes
checking whether feof_unlocked is declared... yes
checking whether ferror_unlocked is declared... yes
checking whether fflush_unlocked is declared... no
checking whether fgets_unlocked is declared... no
checking whether fputc_unlocked is declared... no
checking whether fputs_unlocked is declared... no
checking whether fread_unlocked is declared... no
checking whether fwrite_unlocked is declared... no
checking whether getc_unlocked is declared... yes
checking whether getchar_unlocked is declared... yes
checking whether putc_unlocked is declared... yes
checking whether putchar_unlocked is declared... yes
checking whether the utimes function works... yes
checking type of array argument to getgroups... gid_t
checking whether getdtablesize is declared... yes
checking sys/acl.h usability... yes
checking sys/acl.h presence... yes
checking for sys/acl.h... yes
checking for library containing acl_get_file... none required
checking for acl_get_file... yes
checking for acl_get_fd... yes
checking for acl_set_file... yes
checking for acl_set_fd... yes
checking for acl_free... yes
checking for acl_from_mode... no
checking for acl_from_text... yes
checking for acl_delete_def_file... yes
checking for acl_extended_file... no
checking for acl_delete_fd_np... yes
checking for acl_delete_file_np... yes
checking for acl_copy_ext_native... yes
checking for acl_create_entry_np... yes
checking for acl_to_short_text... no
checking for acl_free_text... no
checking for working acl_get_file... yes
checking acl/libacl.h usability... no
checking acl/libacl.h presence... no
checking for acl/libacl.h... no
checking for acl_entries... no
checking for ACL_FIRST_ENTRY... yes
checking for ACL_TYPE_EXTENDED... yes
checking for alloca as a compiler built-in... yes
checking byteswap.h usability... no
checking byteswap.h presence... no
checking for byteswap.h... no
checking for library containing clock_gettime... no
checking for clock_gettime... no
checking for clock_settime... no
checking whether dup2 works... yes
checking for library containing backtrace_symbols_fd... none required
checking for explicit_memset... no
checking for access... yes
checking whether fcntl handles F_DUPFD correctly... yes
checking whether fcntl understands F_DUPFD_CLOEXEC... no
checking for fdatasync... yes
checking whether fdopendir is declared... no
checking for flexible array member... yes
checking for __fpending... no
checking for getloadavg... yes
checking sys/loadavg.h usability... no
checking sys/loadavg.h presence... no
checking for sys/loadavg.h... no
checking whether getloadavg is declared... yes
checking whether gettimeofday clobbers localtime buffer... no
checking for gettimeofday with POSIX signature... yes
checking for memrchr... no
checking whether signature of pselect conforms to POSIX... yes
checking whether pselect detects invalid fds... yes
checking whether pthread_sigmask works without -lpthread... yes
checking whether pthread_sigmask returns error numbers... yes
checking whether pthread_sigmask unblocks signals correctly... guessing yes
checking whether readlink signature is correct... yes
checking whether readlink handles trailing slash correctly... no
checking for sig2str... no
checking for volatile sig_atomic_t... yes
checking for sighandler_t... no
checking for socklen_t... yes
checking for ssize_t... yes
checking for struct stat.st_atim.tv_nsec... no
checking for struct stat.st_atimespec.tv_nsec... yes
checking for struct stat.st_birthtimespec.tv_nsec... yes
checking for working stdalign.h... no
checking for max_align_t... no
checking whether NULL can be used in arbitrary expressions... yes
checking which flavor of printf attribute matches inttypes macros... system
checking for stpcpy... yes
checking whether strtoimax works... yes
checking whether symlink handles trailing slash correctly... no
checking for nlink_t... yes
checking whether localtime_r is declared... yes
checking whether localtime_r is compatible with its POSIX signature... yes
checking for timezone_t... no
checking for library containing timer_settime... no
checking for timer_settime... no
checking for variable-length arrays... yes
checking for euidaccess... no
checking libgen.h usability... yes
checking libgen.h presence... yes
checking for libgen.h... yes
checking for getgroups... yes
checking for working getgroups... yes
checking for library containing eaccess... no
checking for eaccess... no
checking for group_member... no
checking for getgroups... (cached) yes
checking for working getgroups... (cached) yes
checking whether getgroups handles negative values... no
checking whether getdtablesize works... yes
checking for dirfd... no
checking whether dirfd is declared... yes
checking whether dirfd is a macro... yes
checking for __secure_getenv... no
checking for issetugid... yes
checking for __mktime_internal... no
checking for gcc -std=gnu99 option to disable position independent executables... -no-pie
Configured for 'x86_64-apple-darwin10.8.0'.
Where should the build process find the source code? .
What compiler should emacs be built with? gcc -std=gnu99 -g3 -O2
Should Emacs use the GNU version of malloc? no
(The GNU allocators don't work with this system configuration.)
Should Emacs use a relocating allocator for buffers? no
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? nextstep
What toolkit should Emacs use? none
Where do we find X Windows header files? Standard dirs
Where do we find X Windows libraries? /usr/X11/lib
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use a gif library? no
Does Emacs use a png library? no
Does Emacs use -lrsvg-2? no
Does Emacs use cairo? no
Does Emacs use imagemagick? no
Does Emacs support sound? no
Does Emacs use -lgpm? no
Does Emacs use -ldbus? no
Does Emacs use -lgconf? no
Does Emacs use GSettings? no
Does Emacs use a file notification library? yes (kqueue)
Does Emacs use access control lists? yes
Does Emacs use -lselinux? no
Does Emacs use -lgnutls? no
Does Emacs use -lxml2? yes
Does Emacs use -lfreetype? no
Does Emacs use -lm17n-flt? no
Does Emacs use -lotf? no
Does Emacs use -lxft? no
Does Emacs use -lsystemd? no
Does Emacs directly use zlib? yes
Does Emacs have dynamic modules support? no
Does Emacs use toolkit scroll bars? yes
Does Emacs support Xwidgets (requires gtk3)? no
Does Emacs have threading support in lisp? yes
You must run "make install" in order to test the built application.
The installed application will go to nextstep/Emacs.app and can be
run or moved from there.
The application will be fully self-contained.
configure: creating ./config.status
config.status: creating src/emacs-module.h
config.status: creating nextstep/Cocoa/Emacs.base/Contents/Info.plist
config.status: creating nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/InfoPlist.strings
config.status: creating Makefile
config.status: creating lib/gnulib.mk
config.status: creating ./doc/man/emacs.1
config.status: creating lib/Makefile
config.status: creating lib-src/Makefile
config.status: creating oldXMenu/Makefile
config.status: creating doc/emacs/Makefile
config.status: creating doc/misc/Makefile
config.status: creating doc/lispintro/Makefile
config.status: creating doc/lispref/Makefile
config.status: creating src/Makefile
config.status: creating lwlib/Makefile
config.status: creating lisp/Makefile
config.status: creating leim/Makefile
config.status: creating nextstep/Makefile
config.status: creating nt/Makefile
config.status: creating test/Makefile
config.status: creating admin/charsets/Makefile
config.status: creating admin/unidata/Makefile
config.status: creating admin/grammars/Makefile
config.status: creating src/config.h
config.status: executing src/epaths.h commands
config.status: executing src/.gdbinit commands
config.status: executing doc/emacs/emacsver.texi commands
config.status: executing etc-refcards-emacsver.tex commands
server:emacs HOME$ make
make -C lib all
GEN alloca.h
GEN byteswap.h
GEN dirent.h
GEN errno.h
GEN fcntl.h
GEN getopt.h
GEN getopt-cdefs.h
GEN inttypes.h
GEN limits.h
GEN signal.h
GEN stdalign.h
GEN stddef.h
GEN stdint.h
GEN stdio.h
GEN stdlib.h
GEN string.h
GEN sys/select.h
GEN sys/stat.h
GEN sys/time.h
GEN sys/types.h
GEN time.h
GEN unistd.h
***
ELC org/org-mouse.elc
ELC org/org-pcomplete.elc
ELC org/org-plot.elc
ELC org/org-protocol.elc
ELC org/org-rmail.elc
ELC org/org-src.elc
ELC org/org-table.elc
ELC org/org-timer.elc
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 16:10 ` Keith David Bershatsky
@ 2017-07-17 16:38 ` Noam Postavsky
0 siblings, 0 replies; 39+ messages in thread
From: Noam Postavsky @ 2017-07-17 16:38 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
On Mon, Jul 17, 2017 at 12:10 PM, Keith David Bershatsky
<esq@lawlist.com> wrote:
>> Can you clarify if it works outside eshell?
>
> Thank you for taking a look at this bug report. I just tried building master branch from Terminal.app on OSX 10.6.8 -- without using Emacs -- and I had the same results. I.e., it stops when it gets to "ELC org/org-timer.elc". There is no error message.
Okay, so not an eshell problem then. Is it an infloop stop (i.e.,
maxing out CPU) or waiting for input type of stop? Please try with
'make V=1' to get the exact command being run, and then try running
that command adding '--eval (setq debug-on-quit t)' and removing
'-batch'. If you can't get a lisp trace with C-g using that method,
try running the command under gdb to get a C backtrace.
On Mon, Jul 17, 2017 at 11:18 AM, Keith David Bershatsky
<esq@lawlist.com> wrote:
> ~/Desktop $ git clone -b master git://git.sv.gnu.org/emacs.git
> Cloning into 'emacs'...
[...]
> Checking out files: 100% (3773/3773), done.
>
> ~/Desktop $ cd emacs
>
> ~/Desktop/emacs $ ./autogen.sh
> Checking whether you have the necessary tools...
> (Read INSTALL.REPO for more details on building Emacs)
> Checking for autoconf (need at least version 2.65) ... ok
> Your system has the required tools.
> Building aclocal.m4 ...
> Running 'autoreconf -fi -I m4' ...
> ./autogen.sh: line 274: git: command not found
Hmm, I wonder how come ./autogen.sh can't find 'git'? Shell alias?
Sneaky $PATH change?
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
2017-07-17 15:29 ` Noam Postavsky
2017-07-17 16:10 ` Keith David Bershatsky
@ 2017-07-17 18:05 ` Keith David Bershatsky
2017-07-17 18:48 ` Noam Postavsky
2017-07-17 19:43 ` Alan Third
` (9 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-07-17 18:05 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 27736
I'll keep working on debugging. At the moment, I'm leaning towards believing that it is a never-ending loop that is trying to find `org-element-update-syntax`. That is why there is no error.
The git command cannot be located because its location has not been added to the $PATH. I like to limit the build to the absolute bare minimum, and the directory containing git has a bunch of other stuff that Emacs would see as being available and automatically install them. So, I'd need to add a bunch of exclusion lines to the configuration of Emacs to get the same results of a barebones build. The only thing extra that doesn't come with 10.6.8 and the optional Developer tools are the fairly recent versions of autoconf and automake, which are in a directory all by themselves and I add that autoconf/automake directory to the $PATH before building.
server:emacs HOME$ make V=1
make -C lib all
make[1]: Nothing to be done for `all'.
make -C lib-src all
make[1]: Nothing to be done for `all'.
make -C src VCSWITNESS='$(srcdir)/../.git/logs/HEAD' all
make[1]: Circular bootstrap-emacs <- temacs dependency dropped.
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Nothing to be done for `all'.
make -C ../admin/charsets all
make[2]: Nothing to be done for `all'.
make -C ../admin/unidata charscript.el
make[2]: Nothing to be done for `charscript.el'.
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[2]: Nothing to be done for `all'.
make -C ../admin/charsets cp51932.el
make[2]: Nothing to be done for `cp51932.el'.
make -C ../admin/charsets eucjp-ms.el
make[2]: Nothing to be done for `eucjp-ms.el'.
make -C ../nextstep all
make -C ../src emacs
make[3]: Circular bootstrap-emacs <- temacs dependency dropped.
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[4]: Nothing to be done for `all'.
make -C ../admin/charsets all
make[4]: Nothing to be done for `all'.
make -C ../admin/unidata charscript.el
make[4]: Nothing to be done for `charscript.el'.
make -C ../admin/unidata all EMACS="../../src/bootstrap-emacs"
make[4]: Nothing to be done for `all'.
make -C ../admin/charsets cp51932.el
make[4]: Nothing to be done for `cp51932.el'.
make -C ../admin/charsets eucjp-ms.el
make[4]: Nothing to be done for `eucjp-ms.el'.
make -C lisp all
make -C ../leim all EMACS="../src/emacs"
make[2]: Nothing to be done for `all'.
make -C ../admin/grammars all EMACS="../../src/emacs"
make[2]: Nothing to be done for `all'.
EMACSLOADPATH= '../src/emacs' -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile org/org-timer.el
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 18:05 ` Keith David Bershatsky
@ 2017-07-17 18:48 ` Noam Postavsky
0 siblings, 0 replies; 39+ messages in thread
From: Noam Postavsky @ 2017-07-17 18:48 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
On Mon, Jul 17, 2017 at 2:05 PM, Keith David Bershatsky <esq@lawlist.com> wrote:
> I'll keep working on debugging. At the moment, I'm leaning towards believing that it is a never-ending loop that is trying to find `org-element-update-syntax`. That is why there is no error.
There was an issue with `org-element-update-syntax` caused by the
recent org update, though it should trigger an error, not a hang (and
it's fixed by doing 'make autoloads', see Bug#27581. Should be
irrelevant if you're building from a fresh clone, I think).
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (2 preceding siblings ...)
2017-07-17 18:05 ` Keith David Bershatsky
@ 2017-07-17 19:43 ` Alan Third
2017-07-17 20:48 ` Charles A. Roelli
2017-07-17 21:37 ` Keith David Bershatsky
` (8 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Alan Third @ 2017-07-17 19:43 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
On Mon, Jul 17, 2017 at 08:18:47AM -0700, Keith David Bershatsky wrote:
> I am unable to build Emacs from the master branch on OSX 10.6.8 with
> Eshell, which is what I have used for several years. It just
> stops/freezes when it gets to: "ELC org/org-timer.elc". I am still
> able to successfully build earlier versions of Emacs master branch
> from last year -- I am unsure what specific day the builds stopped
> working. I tried yesterday and today, with the same results:
I believe this is the same as bug#27706.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27706
I can’t reproduce on 10.12, so it looks like a bug in older macOS
versions, although I don’t know just how old.
--
Alan Third
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 19:43 ` Alan Third
@ 2017-07-17 20:48 ` Charles A. Roelli
0 siblings, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2017-07-17 20:48 UTC (permalink / raw)
To: 27736
On 17/07/2017 21:43, Alan Third wrote:
> On Mon, Jul 17, 2017 at 08:18:47AM -0700, Keith David Bershatsky wrote:
>> I am unable to build Emacs from the master branch on OSX 10.6.8 with
>> Eshell, which is what I have used for several years. It just
>> stops/freezes when it gets to: "ELC org/org-timer.elc". I am still
>> able to successfully build earlier versions of Emacs master branch
>> from last year -- I am unsure what specific day the builds stopped
>> working. I tried yesterday and today, with the same results:
>
> I believe this is the same as bug#27706.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27706
>
> I can’t reproduce on 10.12, so it looks like a bug in older macOS
> versions, although I don’t know just how old.
Indeed, this does look like the same bug. I have the exact same problem.
Keith: can you get a backtrace from the compile process?
If you have GDB installed, you might see something like this:
(gdb) bt
#0 0x00007fff83860c0d in timesub () from /usr/lib/libSystem.B.dylib
#1 0x00007fff8386081c in _st_localsub () from /usr/lib/libSystem.B.dylib
#2 0x00007fff83869d71 in localtime_r () from /usr/lib/libSystem.B.dylib
#3 0x0000000100458747 in localtime_rz (tz=0x102104250,
t=0x7fff5fbe8be0, tm=0x7fff5fbe8ba8) at time_rz.c:296
#4 0x00000001002ba1eb in emacs_localtime_rz (tz=0x102104250,
t=0x7fff5fbe8be0, tm=0x7fff5fbe8ba8) at editfns.c:103
#5 0x00000001002c27e0 in Fdecode_time (specified_time=..., zone=...) at
editfns.c:2163
#6 0x00000001002e66f4 in funcall_subr (subr=0x100921998 <Sdecode_time>,
numargs=1, args=0x7fff5fbe9028) at eval.c:2824
#7 0x00000001002e5eaa in Ffuncall (nargs=2, args=0x7fff5fbe9020) at
eval.c:2747
#8 0x0000000100369d53 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7fff5fbea288) at
bytecode.c:629
#9 0x00000001002e73c6 in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7fff5fbea280) at eval.c:2948
#10 0x00000001002e5f1d in Ffuncall (nargs=2, args=0x7fff5fbea278) at
eval.c:2749
#11 0x0000000100369d53 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=3, args=0x7fff5fbeb510) at
bytecode.c:629
#12 0x00000001002e73c6 in funcall_lambda (fun=..., nargs=3,
arg_vector=0x7fff5fbeb4f8) at eval.c:2948
#13 0x00000001002e5f1d in Ffuncall (nargs=4, args=0x7fff5fbeb4f0) at
eval.c:2749
#14 0x0000000100369d53 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:629
#15 0x0000000100368538 in Fbyte_code (bytestr=..., vector=...,
maxdepth=...) at bytecode.c:321
#16 0x00000001002e3359 in eval_sub (form=...) at eval.c:2229
#17 0x00000001002dc085 in Fdefconst (args=...) at eval.c:816
#18 0x00000001002e2c98 in eval_sub (form=...) at eval.c:2176
#19 0x000000010033cb46 in readevalloop (readcharfun=...,
infile0=0x7fff5fbed6c8, sourcename=..., printflag=false, unibyte=...,
readfun=..., start=..., end=...) at lread.c:2038
#20 0x0000000100339754 in Fload (file=..., noerror=..., nomessage=...,
nosuffix=..., must_suffix=...) at lread.c:1425
#21 0x00000001002fcf8b in Frequire (feature=..., filename=...,
noerror=...) at fns.c:2796
[...]
(gdb) select 5
#5 0x00000001002c27e0 in Fdecode_time (specified_time=..., zone=...) at
editfns.c:2163
2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
(gdb) pp specified_time
(-1034058203136 0) [from GDB's I/O buffer]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (3 preceding siblings ...)
2017-07-17 19:43 ` Alan Third
@ 2017-07-17 21:37 ` Keith David Bershatsky
2017-07-18 5:08 ` Charles A. Roelli
2017-07-18 6:56 ` Keith David Bershatsky
` (7 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-07-17 21:37 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: Alan Third, 27736, Noam Postavsky
I have not yet learned how to use gdb while building Emacs. Here are the steps I used with both ggdb and gdb following a failed build of Emacs. I have labeled ggdb and gdb with BEGIN/END to distinguish between the two reports below.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; BEGIN ggdb
Last login: Mon Jul 17 14:26:40 on ttys000
server:~ HOME$ sudo /Users/HOME/.0.data/.0.emacs/.0.macports/bin/ggdb /Users/HOME/Desktop/emacs/src/emacs
Password:
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10.8.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /Users/HOME/Desktop/emacs/src/emacs...done.
(gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
[New Thread 0x60f of process 1654]
[New Thread 0x70f of process 1654]
^C
Program received signal SIGINT, Interrupt.
0x00007fff87007b3a in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
(gdb) bt
#0 0x00007fff87007b3a in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#1 0x00007fff8700781c in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#2 0x00007fff87010d71 in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#3 0x00000001001c3883 in localtime_rz (tz=0x100d06100, t=0x7fff5fbfc208,
tm=0x7fff5fbfc1d0) at time_rz.c:296
#4 0x000000010011d02e in emacs_localtime_rz (tz=0xffffffff800007b0,
t=0xa3d70a3d70a3d70b, tm=0x147ae00) at editfns.c:103
#5 0x000000010011e742 in Fdecode_time (specified_time=<optimized out>, zone=0)
at editfns.c:2163
#6 0x000000010012d55e in funcall_subr (subr=0x1005b03b8 <Sdecode_time>,
numargs=1, args=0xfffffffffeb851ff) at eval.c:2817
#7 0x000000010012b716 in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at eval.c:2740
#8 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680,
vector=-6640827866535438581, maxdepth=21474816, args_template=1030,
nargs=1, args=0x7fff5fbfc4b8) at bytecode.c:629
#9 0x000000010012b67a in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at eval.c:2754
#10 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680,
vector=-6640827866535438581, maxdepth=21474816, args_template=3086,
nargs=3, args=0x7fff5fbfc660) at bytecode.c:629
#11 0x000000010012b67a in Ffuncall (nargs=<optimized out>,
args=<optimized out>) at eval.c:2754
---Type <return> to continue, or q <return> to quit---
;;; END ggdb
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; BEGIN gdb
Last login: Mon Jul 17 14:22:48 on ttys000
server:~ HOME$ gdb /Users/HOME/Desktop/emacs/src/emacsGNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done
(gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Reading symbols for shared libraries .++++++++++............................................................................... done
^C
Program received signal SIGINT, Interrupt.
0x00007fff87007b17 in timesub ()
(gdb) bt
#0 0x00007fff87007b17 in timesub ()
#1 0x00007fff8700781c in _st_localsub ()
#2 0x00007fff87010d71 in localtime_r ()
#3 0x00000001001c3883 in localtime_rz (tz=0x100c08360, t=0x7fff5fbfc188, tm=0x7fff5fbfc150) at time_rz.c:296
#4 0x000000010011d02e in emacs_localtime_rz (tz=<value temporarily unavailable, due to optimizations>, t=<value temporarily unavailable, due to optimizations>, tm=<value temporarily unavailable, due to optimizations>) at editfns.c:103
#5 0x000000010011e742 in Fdecode_time (specified_time=<value temporarily unavailable, due to optimizations>, zone=0) at editfns.c:2163
#6 0x000000010012d55e in funcall_subr (subr=0x1005b03b8, numargs=1, args=<value temporarily unavailable, due to optimizations>) at eval.c:2817
#7 0x000000010012b716 in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2740
#8 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680, vector=-6640827866535438581, maxdepth=773093404, args_template=1030, nargs=1, args=0x7fff5fbfc438) at bytecode.c:629
#9 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#10 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680, vector=-6640827866535438581, maxdepth=773093404, args_template=3086, nargs=3, args=0x7fff5fbfc5e0) at bytecode.c:629
#11 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#12 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680, vector=-6640827866535438581, maxdepth=773093404, args_template=0, nargs=0, args=0x0) at bytecode.c:629
#13 0x000000010012ae43 in eval_sub (form=<value temporarily unavailable, due to optimizations>) at eval.c:2222
#14 0x000000010012ddbc in builtin_lisp_symbol [inlined] () at eval.c:809
#15 0x000000010012ddbc in make_lisp_symbol [inlined] () at eval.c:1149
#16 0x000000010012ddbc in NILP [inlined] () at /Users/HOME/Desktop/emacs/src/lisp.h:841
#17 0x000000010012ddbc in Fdefconst (args=<value temporarily unavailable, due to optimizations>) at eval.c:810
#18 0x000000010012af47 in eval_sub (form=<value temporarily unavailable, due to optimizations>) at eval.c:2169
#19 0x0000000100150758 in readevalloop (readcharfun=24096, infile0=0x7fff5fbfcb40, sourcename=4307660020, printflag=false, unibyte=<value temporarily unavailable, due to optimizations>, readfun=0, start=0, end=0) at lread.c:2038
#20 0x000000010015331c in Fload (file=4307658100, noerror=<value temporarily unavailable, due to optimizations>, nomessage=45360, nosuffix=<value temporarily unavailable, due to optimizations>, must_suffix=<value temporarily unavailable, due to optimizations>) at lread.c:1425
#21 0x000000010013628f in Frequire (feature=136412192, filename=4307658100, noerror=0) at fns.c:2801
#22 0x000000010012d54e in funcall_subr (subr=0x1005b2430, numargs=1, args=<value temporarily unavailable, due to optimizations>) at eval.c:2820
#23 0x000000010012b716 in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2740
#24 0x000000010012bda8 in Fapply (nargs=2, args=0x7fff5fbfce68) at eval.c:2328
#25 0x000000010012d472 in funcall_subr (subr=0x1005b0e40, numargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:2795
#26 0x000000010012b716 in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2740
#27 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd058) at bytecode.c:629
#28 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#29 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd1d0) at bytecode.c:629
#30 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#31 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd338) at bytecode.c:629
#32 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#33 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2058, nargs=2, args=0x7fff5fbfd4d8) at bytecode.c:629
#34 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#35 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd628) at bytecode.c:629
#36 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#37 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd820) at bytecode.c:629
#38 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#39 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfdaf8) at bytecode.c:629
#40 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#41 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2054, nargs=1, args=0x7fff5fbfde40) at bytecode.c:629
#42 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#43 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfe018) at bytecode.c:629
#44 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#45 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1026, nargs=0, args=0x7fff5fbfe288) at bytecode.c:629
#46 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#47 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfe8a8) at bytecode.c:629
#48 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#49 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2, nargs=0, args=0x7fff5fbff158) at bytecode.c:629
#50 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
#51 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2, nargs=0, args=0x7fff5fbff440) at bytecode.c:629
#52 0x000000010012c985 in apply_lambda (fun=4298459597, args=<value temporarily unavailable, due to optimizations>, count=4) at eval.c:2877
#53 0x000000010012aa20 in eval_sub (form=<value temporarily unavailable, due to optimizations>) at eval.c:2291
#54 0x000000010012cd0a in Feval (form=4363374275, lexical=<value temporarily unavailable, due to optimizations>) at eval.c:2038
#55 0x0000000100129b23 in internal_condition_case (bfun=0x1000b71f0 <top_level_2>, handlers=<value temporarily unavailable, due to optimizations>, hfun=0x1000b9eb0 <cmd_error>) at eval.c:1319
#56 0x00000001000b7978 in top_level_1 (ignore=<value temporarily unavailable, due to optimizations>) at keyboard.c:1131
#57 0x0000000100129ba7 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000b7920 <top_level_1>, arg=0) at eval.c:1084
#58 0x00000001000b7082 in command_loop () at keyboard.c:1092
#59 0x00000001000b716d in recursive_edit_1 () at keyboard.c:699
#60 0x00000001000ba19a in Frecursive_edit () at keyboard.c:770
#61 0x00000001000aff98 in main (argc=9, argv=0x7fff5fbff908) at emacs.c:1706
(gdb)
;;; END gdb
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 21:37 ` Keith David Bershatsky
@ 2017-07-18 5:08 ` Charles A. Roelli
0 siblings, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2017-07-18 5:08 UTC (permalink / raw)
To: 27736; +Cc: alan, npostavs
Thanks for posting the traces. It looks like your second trace
matches the one I posted. Can you please rebuild with debugging
symbols (see etc/DEBUG) and then run the same commands that I showed
(select 5, pp specified_time)?
On 17/07/2017 23:37, Keith David Bershatsky wrote:
> I have not yet learned how to use gdb while building Emacs. Here are the steps I used with both ggdb and gdb following a failed build of Emacs. I have labeled ggdb and gdb with BEGIN/END to distinguish between the two reports below.
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;; BEGIN ggdb
>
> Last login: Mon Jul 17 14:26:40 on ttys000
> server:~ HOME$ sudo /Users/HOME/.0.data/.0.emacs/.0.macports/bin/ggdb /Users/HOME/Desktop/emacs/src/emacs
> Password:
> GNU gdb (GDB) 7.9.1
> Copyright (C) 2015 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin10.8.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /Users/HOME/Desktop/emacs/src/emacs...done.
> (gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
> Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
> [New Thread 0x60f of process 1654]
> [New Thread 0x70f of process 1654]
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00007fff87007b3a in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
> (gdb) bt
> #0 0x00007fff87007b3a in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
> #1 0x00007fff8700781c in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
> #2 0x00007fff87010d71 in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
> #3 0x00000001001c3883 in localtime_rz (tz=0x100d06100, t=0x7fff5fbfc208,
> tm=0x7fff5fbfc1d0) at time_rz.c:296
> #4 0x000000010011d02e in emacs_localtime_rz (tz=0xffffffff800007b0,
> t=0xa3d70a3d70a3d70b, tm=0x147ae00) at editfns.c:103
> #5 0x000000010011e742 in Fdecode_time (specified_time=<optimized out>, zone=0)
> at editfns.c:2163
> #6 0x000000010012d55e in funcall_subr (subr=0x1005b03b8 <Sdecode_time>,
> numargs=1, args=0xfffffffffeb851ff) at eval.c:2817
> #7 0x000000010012b716 in Ffuncall (nargs=<optimized out>,
> args=<optimized out>) at eval.c:2740
> #8 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680,
> vector=-6640827866535438581, maxdepth=21474816, args_template=1030,
> nargs=1, args=0x7fff5fbfc4b8) at bytecode.c:629
> #9 0x000000010012b67a in Ffuncall (nargs=<optimized out>,
> args=<optimized out>) at eval.c:2754
> #10 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680,
> vector=-6640827866535438581, maxdepth=21474816, args_template=3086,
> nargs=3, args=0x7fff5fbfc660) at bytecode.c:629
> #11 0x000000010012b67a in Ffuncall (nargs=<optimized out>,
> args=<optimized out>) at eval.c:2754
> ---Type <return> to continue, or q <return> to quit---
>
> ;;; END ggdb
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> ;;; BEGIN gdb
>
> Last login: Mon Jul 17 14:22:48 on ttys000
> server:~ HOME$ gdb /Users/HOME/Desktop/emacs/src/emacsGNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done
>
> (gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
> Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
> Reading symbols for shared libraries .++++++++++............................................................................... done
> ^C
> Program received signal SIGINT, Interrupt.
> 0x00007fff87007b17 in timesub ()
> (gdb) bt
> #0 0x00007fff87007b17 in timesub ()
> #1 0x00007fff8700781c in _st_localsub ()
> #2 0x00007fff87010d71 in localtime_r ()
> #3 0x00000001001c3883 in localtime_rz (tz=0x100c08360, t=0x7fff5fbfc188, tm=0x7fff5fbfc150) at time_rz.c:296
> #4 0x000000010011d02e in emacs_localtime_rz (tz=<value temporarily unavailable, due to optimizations>, t=<value temporarily unavailable, due to optimizations>, tm=<value temporarily unavailable, due to optimizations>) at editfns.c:103
> #5 0x000000010011e742 in Fdecode_time (specified_time=<value temporarily unavailable, due to optimizations>, zone=0) at editfns.c:2163
> #6 0x000000010012d55e in funcall_subr (subr=0x1005b03b8, numargs=1, args=<value temporarily unavailable, due to optimizations>) at eval.c:2817
> #7 0x000000010012b716 in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2740
> #8 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680, vector=-6640827866535438581, maxdepth=773093404, args_template=1030, nargs=1, args=0x7fff5fbfc438) at bytecode.c:629
> #9 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #10 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680, vector=-6640827866535438581, maxdepth=773093404, args_template=3086, nargs=3, args=0x7fff5fbfc5e0) at bytecode.c:629
> #11 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #12 0x00000001001651d7 in exec_byte_code (bytestr=-2147481680, vector=-6640827866535438581, maxdepth=773093404, args_template=0, nargs=0, args=0x0) at bytecode.c:629
> #13 0x000000010012ae43 in eval_sub (form=<value temporarily unavailable, due to optimizations>) at eval.c:2222
> #14 0x000000010012ddbc in builtin_lisp_symbol [inlined] () at eval.c:809
> #15 0x000000010012ddbc in make_lisp_symbol [inlined] () at eval.c:1149
> #16 0x000000010012ddbc in NILP [inlined] () at /Users/HOME/Desktop/emacs/src/lisp.h:841
> #17 0x000000010012ddbc in Fdefconst (args=<value temporarily unavailable, due to optimizations>) at eval.c:810
> #18 0x000000010012af47 in eval_sub (form=<value temporarily unavailable, due to optimizations>) at eval.c:2169
> #19 0x0000000100150758 in readevalloop (readcharfun=24096, infile0=0x7fff5fbfcb40, sourcename=4307660020, printflag=false, unibyte=<value temporarily unavailable, due to optimizations>, readfun=0, start=0, end=0) at lread.c:2038
> #20 0x000000010015331c in Fload (file=4307658100, noerror=<value temporarily unavailable, due to optimizations>, nomessage=45360, nosuffix=<value temporarily unavailable, due to optimizations>, must_suffix=<value temporarily unavailable, due to optimizations>) at lread.c:1425
> #21 0x000000010013628f in Frequire (feature=136412192, filename=4307658100, noerror=0) at fns.c:2801
> #22 0x000000010012d54e in funcall_subr (subr=0x1005b2430, numargs=1, args=<value temporarily unavailable, due to optimizations>) at eval.c:2820
> #23 0x000000010012b716 in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2740
> #24 0x000000010012bda8 in Fapply (nargs=2, args=0x7fff5fbfce68) at eval.c:2328
> #25 0x000000010012d472 in funcall_subr (subr=0x1005b0e40, numargs=2, args=<value temporarily unavailable, due to optimizations>) at eval.c:2795
> #26 0x000000010012b716 in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2740
> #27 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd058) at bytecode.c:629
> #28 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #29 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd1d0) at bytecode.c:629
> #30 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #31 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd338) at bytecode.c:629
> #32 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #33 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2058, nargs=2, args=0x7fff5fbfd4d8) at bytecode.c:629
> #34 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #35 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd628) at bytecode.c:629
> #36 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #37 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfd820) at bytecode.c:629
> #38 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #39 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfdaf8) at bytecode.c:629
> #40 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #41 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2054, nargs=1, args=0x7fff5fbfde40) at bytecode.c:629
> #42 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #43 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfe018) at bytecode.c:629
> #44 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #45 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1026, nargs=0, args=0x7fff5fbfe288) at bytecode.c:629
> #46 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #47 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=1030, nargs=1, args=0x7fff5fbfe8a8) at bytecode.c:629
> #48 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #49 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2, nargs=0, args=0x7fff5fbff158) at bytecode.c:629
> #50 0x000000010012b67a in Ffuncall (nargs=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>) at eval.c:2754
> #51 0x00000001001651d7 in exec_byte_code (bytestr=2, vector=4307658100, maxdepth=-1000391738987243024, args_template=2, nargs=0, args=0x7fff5fbff440) at bytecode.c:629
> #52 0x000000010012c985 in apply_lambda (fun=4298459597, args=<value temporarily unavailable, due to optimizations>, count=4) at eval.c:2877
> #53 0x000000010012aa20 in eval_sub (form=<value temporarily unavailable, due to optimizations>) at eval.c:2291
> #54 0x000000010012cd0a in Feval (form=4363374275, lexical=<value temporarily unavailable, due to optimizations>) at eval.c:2038
> #55 0x0000000100129b23 in internal_condition_case (bfun=0x1000b71f0 <top_level_2>, handlers=<value temporarily unavailable, due to optimizations>, hfun=0x1000b9eb0 <cmd_error>) at eval.c:1319
> #56 0x00000001000b7978 in top_level_1 (ignore=<value temporarily unavailable, due to optimizations>) at keyboard.c:1131
> #57 0x0000000100129ba7 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x1000b7920 <top_level_1>, arg=0) at eval.c:1084
> #58 0x00000001000b7082 in command_loop () at keyboard.c:1092
> #59 0x00000001000b716d in recursive_edit_1 () at keyboard.c:699
> #60 0x00000001000ba19a in Frecursive_edit () at keyboard.c:770
> #61 0x00000001000aff98 in main (argc=9, argv=0x7fff5fbff908) at emacs.c:1706
> (gdb)
>
> ;;; END gdb
>
>
>
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (4 preceding siblings ...)
2017-07-17 21:37 ` Keith David Bershatsky
@ 2017-07-18 6:56 ` Keith David Bershatsky
2017-07-18 14:34 ` Eli Zaretskii
2017-07-18 16:07 ` Keith David Bershatsky
` (6 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-07-18 6:56 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: Alan Third, 27736, Noam Postavsky
Neither of my gdb or ggdb versions show anything for "select 5" and "pp" is not recognized. I thought perhaps "frame 5" and "print specified_time" might be fairly close to what it is that you seek, but I'm just guessing.
(gdb) frame 5
#5 0x00000001001e9746 in Fdecode_time (specified_time={i = 4506560707}, zone={i = 0}) at editfns.c:2163
2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
(gdb) print specified_time
$1 = {
i = 4506560707
}
I built emacs using the following configure options:
CFLAGS='-O0 -g3' ./configure --enable-checking='yes,glyphs' --enable-check-lisp-object-type --with-ns --without-makeinfo --with-gnutls=no --with-mailutils
I ran the backtrace as follows, after manually interrupting the build when it stopped/froze at org-timer.el:
(gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [07-17-2017 22:08:27] <18 Jul 2017 07:08:27 +0200>
FROM: "Charles A. Roelli" <charles@aurox.ch>
>
> Thanks for posting the traces. It looks like your second trace
> matches the one I posted. Can you please rebuild with debugging
> symbols (see etc/DEBUG) and then run the same commands that I showed
> (select 5, pp specified_time)?
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-18 6:56 ` Keith David Bershatsky
@ 2017-07-18 14:34 ` Eli Zaretskii
0 siblings, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2017-07-18 14:34 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: charles, alan, 27736, npostavs
> Date: Mon, 17 Jul 2017 23:56:53 -0700
> From: Keith David Bershatsky <esq@lawlist.com>
> Cc: Alan Third <alan@idiocy.org>, 27736@debbugs.gnu.org,
> Noam Postavsky <npostavs@users.sourceforge.net>
>
> Neither of my gdb or ggdb versions show anything for "select 5" and "pp" is not recognized.
"pp" is defined in src/.gdbinit. You need to tell GDB to read it:
(gdb) source /path/to/emacs/src/.gdbinit
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (5 preceding siblings ...)
2017-07-18 6:56 ` Keith David Bershatsky
@ 2017-07-18 16:07 ` Keith David Bershatsky
2017-07-18 18:42 ` Charles A. Roelli
2017-11-05 18:03 ` Keith David Bershatsky
` (5 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-07-18 16:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 27736, Alan Third, Charles A. Roelli, Noam Postavsky
Thank you, Eli, for teaching me about:
>
> "pp" is defined in src/.gdbinit. You need to tell GDB to read it:
>
> (gdb) source /path/to/emacs/src/.gdbinit
Here is a new backtrace for the frame that deals with decode_time:
(gdb) frame 10
#10 0x00000001001e9746 in Fdecode_time (specified_time={i = 4351999171}, zone={i = 0}) at editfns.c:2163
2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
(gdb) pp specified_time
(-1034058203136 0)
And, here is the whole thing:
Last login: Tue Jul 18 08:48:40 on console
server:emacs HOME$ gdb /Users/HOME/Desktop/emacs/src/emacs
GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done
(gdb) source /Users/HOME/Desktop/emacs/src/.gdbinit
Warning: /Users/HOME/Desktop/emacs/../lwlib: No such file or directory.
DISPLAY = /tmp/launch-uSoMoF/org.x:0
TERM = xterm-color
Breakpoint 1 at 0x100134c52: file emacs.c, line 364.
Breakpoint 2 at 0x100162889: file sysdep.c, line 1016.
/Users/HOME/Desktop/emacs/src/.gdbinit:1273: Error in sourced command file:
Undefined command: "python". Try "help".
(gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Reading symbols for shared libraries .++++++++++............................................................................... done
^C
Breakpoint 1, terminate_due_to_signal (sig=2, backtrace_limit=40) at emacs.c:364
364 signal (sig, SIG_DFL);
(gdb) bt
#0 terminate_due_to_signal (sig=2, backtrace_limit=40) at emacs.c:364
#1 0x0000000100163bdc in handle_fatal_signal (sig=Could not find the frame base for "handle_fatal_signal".
) at sysdep.c:1714
#2 0x0000000100163b10 in deliver_process_signal (sig=2, handler=0x100163bc4 <handle_fatal_signal>) at sysdep.c:1654
#3 0x0000000100163bf6 in deliver_fatal_signal (sig=2) at sysdep.c:1720
#4 <signal handler called>
#5 0x00007fff87007b0a in timesub ()
#6 0x00007fff8700781c in _st_localsub ()
#7 0x00007fff87010d71 in localtime_r ()
#8 0x00000001002f5696 in localtime_rz (tz=0x101000f90, t=0x7fff5fbf9498, tm=0x7fff5fbf93c0) at time_rz.c:296
#9 0x00000001001e3afd in emacs_localtime_rz (tz=0x101000f90, t=0x7fff5fbf9498, tm=0x7fff5fbf93c0) at editfns.c:103
#10 0x00000001001e9746 in Fdecode_time (specified_time={i = 4351999171}, zone={i = 0}) at editfns.c:2163
#11 0x000000010020183b in funcall_subr (subr=0x1007bcdd8, numargs=1, args=0x7fff5fbf9608) at eval.c:2817
#12 0x000000010020133c in Ffuncall (nargs=2, args=0x7fff5fbf9600) at eval.c:2740
#13 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399444}, vector={i = 4352860773}, maxdepth={i = 18}, args_template={i = 1030}, nargs=1, args=0x7fff5fbf9a08) at bytecode.c:629
#14 0x0000000100201fe7 in funcall_lambda (fun={i = 4352860813}, nargs=1, arg_vector=0x7fff5fbf9a00) at eval.c:2941
#15 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbf99f8) at eval.c:2742
#16 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399380}, vector={i = 4352860677}, maxdepth={i = 42}, args_template={i = 3086}, nargs=3, args=0x7fff5fbf9e30) at bytecode.c:629
#17 0x0000000100201fe7 in funcall_lambda (fun={i = 4352860725}, nargs=3, arg_vector=0x7fff5fbf9e18) at eval.c:2941
#18 0x0000000100201374 in Ffuncall (nargs=4, args=0x7fff5fbf9e10) at eval.c:2742
#19 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399348}, vector={i = 4352860861}, maxdepth={i = 46}, args_template={i = 0}, nargs=0, args=0x0) at bytecode.c:629
#20 0x0000000100259e7b in Fbyte_code (bytestr={i = 4333399348}, vector={i = 4352860861}, maxdepth={i = 46}) at bytecode.c:321
#21 0x00000001001ffac1 in eval_sub (form={i = 4352004051}) at eval.c:2222
#22 0x00000001001fb503 in Fdefconst (args={i = 4352004099}) at eval.c:809
#23 0x00000001001ff63a in eval_sub (form={i = 4352004115}) at eval.c:2169
#24 0x0000000100239455 in readevalloop (readcharfun={i = 24096}, infile0=0x7fff5fbfa750, sourcename={i = 4330661364}, printflag=false, unibyte={i = 0}, readfun={i = 0}, start={i = 0}, end={i = 0}) at lread.c:2038
#25 0x0000000100237532 in Fload (file={i = 4331687524}, noerror={i = 0}, nomessage={i = 45360}, nosuffix={i = 0}, must_suffix={i = 45360}) at lread.c:1425
#26 0x0000000100210444 in Frequire (feature={i = 42008288}, filename={i = 0}, noerror={i = 0}) at fns.c:2801
#27 0x000000010020186f in funcall_subr (subr=0x1007bed48, numargs=1, args=0x7fff5fbfacd0) at eval.c:2820
#28 0x000000010020133c in Ffuncall (nargs=2, args=0x7fff5fbfacc8) at eval.c:2740
#29 0x0000000100200087 in Fapply (nargs=2, args=0x7fff5fbfacc8) at eval.c:2328
#30 0x00000001002016cc in funcall_subr (subr=0x1007bda88, numargs=2, args=0x7fff5fbfacc8) at eval.c:2795
#31 0x000000010020133c in Ffuncall (nargs=3, args=0x7fff5fbfacc0) at eval.c:2740
#32 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330679892}, vector={i = 4455527021}, maxdepth={i = 38}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfb138) at bytecode.c:629
#33 0x0000000100201fe7 in funcall_lambda (fun={i = 4455527189}, nargs=1, arg_vector=0x7fff5fbfb130) at eval.c:2941
#34 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb128) at eval.c:2742
#35 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678964}, vector={i = 4455517957}, maxdepth={i = 18}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfb530) at bytecode.c:629
#36 0x0000000100201fe7 in funcall_lambda (fun={i = 4455518005}, nargs=1, arg_vector=0x7fff5fbfb528) at eval.c:2941
#37 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb520) at eval.c:2742
#38 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678836}, vector={i = 4455517813}, maxdepth={i = 22}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfb918) at bytecode.c:629
#39 0x0000000100201fe7 in funcall_lambda (fun={i = 4455517861}, nargs=1, arg_vector=0x7fff5fbfb910) at eval.c:2941
#40 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb908) at eval.c:2742
#41 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330662116}, vector={i = 4455466989}, maxdepth={i = 42}, args_template={i = 2058}, nargs=2, args=0x7fff5fbfbd38) at bytecode.c:629
#42 0x0000000100201fe7 in funcall_lambda (fun={i = 4455467093}, nargs=2, arg_vector=0x7fff5fbfbd28) at eval.c:2941
#43 0x0000000100201374 in Ffuncall (nargs=3, args=0x7fff5fbfbd20) at eval.c:2742
#44 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678804}, vector={i = 4455495149}, maxdepth={i = 18}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfc108) at bytecode.c:629
#45 0x0000000100201fe7 in funcall_lambda (fun={i = 4455517909}, nargs=1, arg_vector=0x7fff5fbfc100) at eval.c:2941
#46 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfc0f8) at eval.c:2742
#47 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330676260}, vector={i = 4455508293}, maxdepth={i = 42}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfc580) at bytecode.c:629
#48 0x0000000100201fe7 in funcall_lambda (fun={i = 4455508517}, nargs=1, arg_vector=0x7fff5fbfc578) at eval.c:2941
#49 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfc570) at eval.c:2742
#50 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330676164}, vector={i = 4455512637}, maxdepth={i = 70}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfcad8) at bytecode.c:629
#51 0x0000000100201fe7 in funcall_lambda (fun={i = 4455508565}, nargs=1, arg_vector=0x7fff5fbfcad0) at eval.c:2941
#52 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfcac8) at eval.c:2742
#53 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330675236}, vector={i = 4455503421}, maxdepth={i = 66}, args_template={i = 2054}, nargs=1, args=0x7fff5fbfd0a0) at bytecode.c:629
#54 0x0000000100201fe7 in funcall_lambda (fun={i = 4455504133}, nargs=1, arg_vector=0x7fff5fbfd098) at eval.c:2941
#55 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfd090) at eval.c:2742
#56 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330698708}, vector={i = 4455656013}, maxdepth={i = 34}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfd4f8) at bytecode.c:629
#57 0x0000000100201fe7 in funcall_lambda (fun={i = 4455647189}, nargs=1, arg_vector=0x7fff5fbfd4f0) at eval.c:2941
#58 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfd4e8) at eval.c:2742
#59 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330698612}, vector={i = 4455660765}, maxdepth={i = 42}, args_template={i = 1026}, nargs=0, args=0x7fff5fbfd9e8) at bytecode.c:629
#60 0x0000000100201fe7 in funcall_lambda (fun={i = 4455647141}, nargs=0, arg_vector=0x7fff5fbfd9e8) at eval.c:2941
#61 0x0000000100201374 in Ffuncall (nargs=1, args=0x7fff5fbfd9e0) at eval.c:2742
#62 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299934692}, vector={i = 4299934725}, maxdepth={i = 94}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfe288) at bytecode.c:629
#63 0x0000000100201fe7 in funcall_lambda (fun={i = 4299934645}, nargs=1, arg_vector=0x7fff5fbfe280) at eval.c:2941
#64 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfe278) at eval.c:2742
#65 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299912628}, vector={i = 4299912661}, maxdepth={i = 86}, args_template={i = 2}, nargs=0, args=0x7fff5fbfedb8) at bytecode.c:629
#66 0x0000000100201fe7 in funcall_lambda (fun={i = 4299912581}, nargs=0, arg_vector=0x7fff5fbfedb8) at eval.c:2941
#67 0x0000000100201374 in Ffuncall (nargs=1, args=0x7fff5fbfedb0) at eval.c:2742
#68 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299908964}, vector={i = 4299908997}, maxdepth={i = 50}, args_template={i = 2}, nargs=0, args=0x7fff5fbff2f0) at bytecode.c:629
#69 0x0000000100201fe7 in funcall_lambda (fun={i = 4299908917}, nargs=0, arg_vector=0x7fff5fbff2f0) at eval.c:2941
#70 0x0000000100201c16 in apply_lambda (fun={i = 4299908917}, args={i = 0}, count=4) at eval.c:2877
#71 0x00000001001ffc89 in eval_sub (form={i = 4379235827}) at eval.c:2261
#72 0x00000001001fef96 in Feval (form={i = 4379235827}, lexical={i = 0}) at eval.c:2038
#73 0x0000000100139c2c in top_level_2 () at keyboard.c:1123
#74 0x00000001001fd0d8 in internal_condition_case (bfun=0x100139c08 <top_level_2>, handlers={i = 18528}, hfun=0x100139519 <cmd_error>) at eval.c:1319
#75 0x0000000100139c78 in top_level_1 (ignore={i = 0}) at keyboard.c:1131
#76 0x00000001001fc551 in internal_catch (tag={i = 46944}, func=0x100139c2e <top_level_1>, arg={i = 0}) at eval.c:1084
#77 0x0000000100139b4d in command_loop () at keyboard.c:1092
#78 0x0000000100138fb0 in recursive_edit_1 () at keyboard.c:699
#79 0x00000001001391c7 in Frecursive_edit () at keyboard.c:770
#80 0x0000000100136cdc in main (argc=9, argv=0x7fff5fbff8e8) at emacs.c:1706
Lisp Backtrace:
"decode-time" (0x5fbf9608)
0x3736288 PVEC_COMPILED
0x3736230 PVEC_COMPILED
"byte-code" (0x5fbfa140)
"defconst" (0x5fbfa3e0)
"require" (0x5fbfacd0)
"apply" (0x5fbfacc8)
"byte-compile-file-form-require" (0x5fbfb130)
"byte-compile-file-form" (0x5fbfb528)
0x991cea0 PVEC_COMPILED
"byte-compile-recurse-toplevel" (0x5fbfbd28)
"byte-compile-toplevel-file-form" (0x5fbfc100)
0x991aa20 PVEC_COMPILED
"byte-compile-from-buffer" (0x5fbfcad0)
"byte-compile-file" (0x5fbfd098)
"batch-byte-compile-file" (0x5fbfd4f0)
"batch-byte-compile" (0x5fbfd9e8)
"command-line-1" (0x5fbfe280)
"command-line" (0x5fbfedb8)
"normal-top-level" (0x5fbff2f0)
(gdb) select 5
(gdb) frame 5
#5 0x00007fff87007b0a in timesub ()
(gdb) frame 10
#10 0x00000001001e9746 in Fdecode_time (specified_time={i = 4351999171}, zone={i = 0}) at editfns.c:2163
2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
(gdb) pp specified_time
(-1034058203136 0)
(gdb)
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-18 16:07 ` Keith David Bershatsky
@ 2017-07-18 18:42 ` Charles A. Roelli
2017-07-19 19:58 ` Charles A. Roelli
0 siblings, 1 reply; 39+ messages in thread
From: Charles A. Roelli @ 2017-07-18 18:42 UTC (permalink / raw)
To: Keith David Bershatsky, Eli Zaretskii; +Cc: Alan Third, 27736, Noam Postavsky
Thanks for checking this so quickly.
It looks like your machine also enters an infinite loop when
evaluating the same form that I posted here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27706#5
I'm not sure where we should patch this issue: in Lisp, in
lib/time_rz.c (which is part of gnulib if I remember right), or in
src/editfns.c (emacs_localtime_rz). Does anyone have an opinion about
this?
On 18/07/2017 18:07, Keith David Bershatsky wrote:
> Thank you, Eli, for teaching me about:
>
>> "pp" is defined in src/.gdbinit. You need to tell GDB to read it:
>>
>> (gdb) source /path/to/emacs/src/.gdbinit
> Here is a new backtrace for the frame that deals with decode_time:
>
> (gdb) frame 10
> #10 0x00000001001e9746 in Fdecode_time (specified_time={i = 4351999171}, zone={i = 0}) at editfns.c:2163
> 2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
> (gdb) pp specified_time
> (-1034058203136 0)
>
> And, here is the whole thing:
>
> Last login: Tue Jul 18 08:48:40 on console
>
> server:emacs HOME$ gdb /Users/HOME/Desktop/emacs/src/emacs
>
> GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56 UTC 2009)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ........... done
>
> (gdb) source /Users/HOME/Desktop/emacs/src/.gdbinit
> Warning: /Users/HOME/Desktop/emacs/../lwlib: No such file or directory.
> DISPLAY = /tmp/launch-uSoMoF/org.x:0
> TERM = xterm-color
> Breakpoint 1 at 0x100134c52: file emacs.c, line 364.
> Breakpoint 2 at 0x100162889: file sysdep.c, line 1016.
> /Users/HOME/Desktop/emacs/src/.gdbinit:1273: Error in sourced command file:
> Undefined command: "python". Try "help".
> (gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
> Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
> Reading symbols for shared libraries .++++++++++............................................................................... done
> ^C
> Breakpoint 1, terminate_due_to_signal (sig=2, backtrace_limit=40) at emacs.c:364
> 364 signal (sig, SIG_DFL);
> (gdb) bt
> #0 terminate_due_to_signal (sig=2, backtrace_limit=40) at emacs.c:364
> #1 0x0000000100163bdc in handle_fatal_signal (sig=Could not find the frame base for "handle_fatal_signal".
> ) at sysdep.c:1714
> #2 0x0000000100163b10 in deliver_process_signal (sig=2, handler=0x100163bc4 <handle_fatal_signal>) at sysdep.c:1654
> #3 0x0000000100163bf6 in deliver_fatal_signal (sig=2) at sysdep.c:1720
> #4 <signal handler called>
> #5 0x00007fff87007b0a in timesub ()
> #6 0x00007fff8700781c in _st_localsub ()
> #7 0x00007fff87010d71 in localtime_r ()
> #8 0x00000001002f5696 in localtime_rz (tz=0x101000f90, t=0x7fff5fbf9498, tm=0x7fff5fbf93c0) at time_rz.c:296
> #9 0x00000001001e3afd in emacs_localtime_rz (tz=0x101000f90, t=0x7fff5fbf9498, tm=0x7fff5fbf93c0) at editfns.c:103
> #10 0x00000001001e9746 in Fdecode_time (specified_time={i = 4351999171}, zone={i = 0}) at editfns.c:2163
> #11 0x000000010020183b in funcall_subr (subr=0x1007bcdd8, numargs=1, args=0x7fff5fbf9608) at eval.c:2817
> #12 0x000000010020133c in Ffuncall (nargs=2, args=0x7fff5fbf9600) at eval.c:2740
> #13 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399444}, vector={i = 4352860773}, maxdepth={i = 18}, args_template={i = 1030}, nargs=1, args=0x7fff5fbf9a08) at bytecode.c:629
> #14 0x0000000100201fe7 in funcall_lambda (fun={i = 4352860813}, nargs=1, arg_vector=0x7fff5fbf9a00) at eval.c:2941
> #15 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbf99f8) at eval.c:2742
> #16 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399380}, vector={i = 4352860677}, maxdepth={i = 42}, args_template={i = 3086}, nargs=3, args=0x7fff5fbf9e30) at bytecode.c:629
> #17 0x0000000100201fe7 in funcall_lambda (fun={i = 4352860725}, nargs=3, arg_vector=0x7fff5fbf9e18) at eval.c:2941
> #18 0x0000000100201374 in Ffuncall (nargs=4, args=0x7fff5fbf9e10) at eval.c:2742
> #19 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399348}, vector={i = 4352860861}, maxdepth={i = 46}, args_template={i = 0}, nargs=0, args=0x0) at bytecode.c:629
> #20 0x0000000100259e7b in Fbyte_code (bytestr={i = 4333399348}, vector={i = 4352860861}, maxdepth={i = 46}) at bytecode.c:321
> #21 0x00000001001ffac1 in eval_sub (form={i = 4352004051}) at eval.c:2222
> #22 0x00000001001fb503 in Fdefconst (args={i = 4352004099}) at eval.c:809
> #23 0x00000001001ff63a in eval_sub (form={i = 4352004115}) at eval.c:2169
> #24 0x0000000100239455 in readevalloop (readcharfun={i = 24096}, infile0=0x7fff5fbfa750, sourcename={i = 4330661364}, printflag=false, unibyte={i = 0}, readfun={i = 0}, start={i = 0}, end={i = 0}) at lread.c:2038
> #25 0x0000000100237532 in Fload (file={i = 4331687524}, noerror={i = 0}, nomessage={i = 45360}, nosuffix={i = 0}, must_suffix={i = 45360}) at lread.c:1425
> #26 0x0000000100210444 in Frequire (feature={i = 42008288}, filename={i = 0}, noerror={i = 0}) at fns.c:2801
> #27 0x000000010020186f in funcall_subr (subr=0x1007bed48, numargs=1, args=0x7fff5fbfacd0) at eval.c:2820
> #28 0x000000010020133c in Ffuncall (nargs=2, args=0x7fff5fbfacc8) at eval.c:2740
> #29 0x0000000100200087 in Fapply (nargs=2, args=0x7fff5fbfacc8) at eval.c:2328
> #30 0x00000001002016cc in funcall_subr (subr=0x1007bda88, numargs=2, args=0x7fff5fbfacc8) at eval.c:2795
> #31 0x000000010020133c in Ffuncall (nargs=3, args=0x7fff5fbfacc0) at eval.c:2740
> #32 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330679892}, vector={i = 4455527021}, maxdepth={i = 38}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfb138) at bytecode.c:629
> #33 0x0000000100201fe7 in funcall_lambda (fun={i = 4455527189}, nargs=1, arg_vector=0x7fff5fbfb130) at eval.c:2941
> #34 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb128) at eval.c:2742
> #35 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678964}, vector={i = 4455517957}, maxdepth={i = 18}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfb530) at bytecode.c:629
> #36 0x0000000100201fe7 in funcall_lambda (fun={i = 4455518005}, nargs=1, arg_vector=0x7fff5fbfb528) at eval.c:2941
> #37 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb520) at eval.c:2742
> #38 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678836}, vector={i = 4455517813}, maxdepth={i = 22}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfb918) at bytecode.c:629
> #39 0x0000000100201fe7 in funcall_lambda (fun={i = 4455517861}, nargs=1, arg_vector=0x7fff5fbfb910) at eval.c:2941
> #40 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb908) at eval.c:2742
> #41 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330662116}, vector={i = 4455466989}, maxdepth={i = 42}, args_template={i = 2058}, nargs=2, args=0x7fff5fbfbd38) at bytecode.c:629
> #42 0x0000000100201fe7 in funcall_lambda (fun={i = 4455467093}, nargs=2, arg_vector=0x7fff5fbfbd28) at eval.c:2941
> #43 0x0000000100201374 in Ffuncall (nargs=3, args=0x7fff5fbfbd20) at eval.c:2742
> #44 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678804}, vector={i = 4455495149}, maxdepth={i = 18}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfc108) at bytecode.c:629
> #45 0x0000000100201fe7 in funcall_lambda (fun={i = 4455517909}, nargs=1, arg_vector=0x7fff5fbfc100) at eval.c:2941
> #46 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfc0f8) at eval.c:2742
> #47 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330676260}, vector={i = 4455508293}, maxdepth={i = 42}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfc580) at bytecode.c:629
> #48 0x0000000100201fe7 in funcall_lambda (fun={i = 4455508517}, nargs=1, arg_vector=0x7fff5fbfc578) at eval.c:2941
> #49 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfc570) at eval.c:2742
> #50 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330676164}, vector={i = 4455512637}, maxdepth={i = 70}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfcad8) at bytecode.c:629
> #51 0x0000000100201fe7 in funcall_lambda (fun={i = 4455508565}, nargs=1, arg_vector=0x7fff5fbfcad0) at eval.c:2941
> #52 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfcac8) at eval.c:2742
> #53 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330675236}, vector={i = 4455503421}, maxdepth={i = 66}, args_template={i = 2054}, nargs=1, args=0x7fff5fbfd0a0) at bytecode.c:629
> #54 0x0000000100201fe7 in funcall_lambda (fun={i = 4455504133}, nargs=1, arg_vector=0x7fff5fbfd098) at eval.c:2941
> #55 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfd090) at eval.c:2742
> #56 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330698708}, vector={i = 4455656013}, maxdepth={i = 34}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfd4f8) at bytecode.c:629
> #57 0x0000000100201fe7 in funcall_lambda (fun={i = 4455647189}, nargs=1, arg_vector=0x7fff5fbfd4f0) at eval.c:2941
> #58 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfd4e8) at eval.c:2742
> #59 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330698612}, vector={i = 4455660765}, maxdepth={i = 42}, args_template={i = 1026}, nargs=0, args=0x7fff5fbfd9e8) at bytecode.c:629
> #60 0x0000000100201fe7 in funcall_lambda (fun={i = 4455647141}, nargs=0, arg_vector=0x7fff5fbfd9e8) at eval.c:2941
> #61 0x0000000100201374 in Ffuncall (nargs=1, args=0x7fff5fbfd9e0) at eval.c:2742
> #62 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299934692}, vector={i = 4299934725}, maxdepth={i = 94}, args_template={i = 1030}, nargs=1, args=0x7fff5fbfe288) at bytecode.c:629
> #63 0x0000000100201fe7 in funcall_lambda (fun={i = 4299934645}, nargs=1, arg_vector=0x7fff5fbfe280) at eval.c:2941
> #64 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfe278) at eval.c:2742
> #65 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299912628}, vector={i = 4299912661}, maxdepth={i = 86}, args_template={i = 2}, nargs=0, args=0x7fff5fbfedb8) at bytecode.c:629
> #66 0x0000000100201fe7 in funcall_lambda (fun={i = 4299912581}, nargs=0, arg_vector=0x7fff5fbfedb8) at eval.c:2941
> #67 0x0000000100201374 in Ffuncall (nargs=1, args=0x7fff5fbfedb0) at eval.c:2742
> #68 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299908964}, vector={i = 4299908997}, maxdepth={i = 50}, args_template={i = 2}, nargs=0, args=0x7fff5fbff2f0) at bytecode.c:629
> #69 0x0000000100201fe7 in funcall_lambda (fun={i = 4299908917}, nargs=0, arg_vector=0x7fff5fbff2f0) at eval.c:2941
> #70 0x0000000100201c16 in apply_lambda (fun={i = 4299908917}, args={i = 0}, count=4) at eval.c:2877
> #71 0x00000001001ffc89 in eval_sub (form={i = 4379235827}) at eval.c:2261
> #72 0x00000001001fef96 in Feval (form={i = 4379235827}, lexical={i = 0}) at eval.c:2038
> #73 0x0000000100139c2c in top_level_2 () at keyboard.c:1123
> #74 0x00000001001fd0d8 in internal_condition_case (bfun=0x100139c08 <top_level_2>, handlers={i = 18528}, hfun=0x100139519 <cmd_error>) at eval.c:1319
> #75 0x0000000100139c78 in top_level_1 (ignore={i = 0}) at keyboard.c:1131
> #76 0x00000001001fc551 in internal_catch (tag={i = 46944}, func=0x100139c2e <top_level_1>, arg={i = 0}) at eval.c:1084
> #77 0x0000000100139b4d in command_loop () at keyboard.c:1092
> #78 0x0000000100138fb0 in recursive_edit_1 () at keyboard.c:699
> #79 0x00000001001391c7 in Frecursive_edit () at keyboard.c:770
> #80 0x0000000100136cdc in main (argc=9, argv=0x7fff5fbff8e8) at emacs.c:1706
>
> Lisp Backtrace:
> "decode-time" (0x5fbf9608)
> 0x3736288 PVEC_COMPILED
> 0x3736230 PVEC_COMPILED
> "byte-code" (0x5fbfa140)
> "defconst" (0x5fbfa3e0)
> "require" (0x5fbfacd0)
> "apply" (0x5fbfacc8)
> "byte-compile-file-form-require" (0x5fbfb130)
> "byte-compile-file-form" (0x5fbfb528)
> 0x991cea0 PVEC_COMPILED
> "byte-compile-recurse-toplevel" (0x5fbfbd28)
> "byte-compile-toplevel-file-form" (0x5fbfc100)
> 0x991aa20 PVEC_COMPILED
> "byte-compile-from-buffer" (0x5fbfcad0)
> "byte-compile-file" (0x5fbfd098)
> "batch-byte-compile-file" (0x5fbfd4f0)
> "batch-byte-compile" (0x5fbfd9e8)
> "command-line-1" (0x5fbfe280)
> "command-line" (0x5fbfedb8)
> "normal-top-level" (0x5fbff2f0)
> (gdb) select 5
> (gdb) frame 5
> #5 0x00007fff87007b0a in timesub ()
> (gdb) frame 10
> #10 0x00000001001e9746 in Fdecode_time (specified_time={i = 4351999171}, zone={i = 0}) at editfns.c:2163
> 2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
> (gdb) pp specified_time
> (-1034058203136 0)
> (gdb)
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-18 18:42 ` Charles A. Roelli
@ 2017-07-19 19:58 ` Charles A. Roelli
2017-07-19 22:48 ` Alan Third
0 siblings, 1 reply; 39+ messages in thread
From: Charles A. Roelli @ 2017-07-19 19:58 UTC (permalink / raw)
To: Keith David Bershatsky, Eli Zaretskii; +Cc: Alan Third, 27736, Noam Postavsky
Err, oops: I guess there will be no patch for this in Lisp, since
decode-time is written in C.
So the choice is either to make a change in lib/time_rz.c or src/editfns.c.
On 18/07/2017 20:42, Charles A. Roelli wrote:
> Thanks for checking this so quickly.
>
> It looks like your machine also enters an infinite loop when
> evaluating the same form that I posted here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27706#5
>
> I'm not sure where we should patch this issue: in Lisp, in
> lib/time_rz.c (which is part of gnulib if I remember right), or in
> src/editfns.c (emacs_localtime_rz). Does anyone have an opinion about
> this?
>
>
> On 18/07/2017 18:07, Keith David Bershatsky wrote:
>> Thank you, Eli, for teaching me about:
>>
>>> "pp" is defined in src/.gdbinit. You need to tell GDB to read it:
>>>
>>> (gdb) source /path/to/emacs/src/.gdbinit
>> Here is a new backtrace for the frame that deals with decode_time:
>>
>> (gdb) frame 10
>> #10 0x00000001001e9746 in Fdecode_time (specified_time={i =
>> 4351999171}, zone={i = 0}) at editfns.c:2163
>> 2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec,
>> &local_tm);
>> (gdb) pp specified_time
>> (-1034058203136 0)
>>
>> And, here is the whole thing:
>>
>> Last login: Tue Jul 18 08:48:40 on console
>>
>> server:emacs HOME$ gdb /Users/HOME/Desktop/emacs/src/emacs
>>
>> GNU gdb 6.3.50-20050815 (Apple version gdb-1344) (Fri Jul 3 01:19:56
>> UTC 2009)
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and
>> you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for
>> details.
>> This GDB was configured as "x86_64-apple-darwin"...Reading symbols
>> for shared libraries ........... done
>>
>> (gdb) source /Users/HOME/Desktop/emacs/src/.gdbinit
>> Warning: /Users/HOME/Desktop/emacs/../lwlib: No such file or directory.
>> DISPLAY = /tmp/launch-uSoMoF/org.x:0
>> TERM = xterm-color
>> Breakpoint 1 at 0x100134c52: file emacs.c, line 364.
>> Breakpoint 2 at 0x100162889: file sysdep.c, line 1016.
>> /Users/HOME/Desktop/emacs/src/.gdbinit:1273: Error in sourced command
>> file:
>> Undefined command: "python". Try "help".
>> (gdb) run -batch --no-site-file --no-site-lisp --eval '(setq
>> load-prefer-newer t)' -f batch-byte-compile
>> /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
>> Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch
>> --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f
>> batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
>> Reading symbols for shared libraries
>> .++++++++++...............................................................................
>> done
>> ^C
>> Breakpoint 1, terminate_due_to_signal (sig=2, backtrace_limit=40) at
>> emacs.c:364
>> 364 signal (sig, SIG_DFL);
>> (gdb) bt
>> #0 terminate_due_to_signal (sig=2, backtrace_limit=40) at emacs.c:364
>> #1 0x0000000100163bdc in handle_fatal_signal (sig=Could not find the
>> frame base for "handle_fatal_signal".
>> ) at sysdep.c:1714
>> #2 0x0000000100163b10 in deliver_process_signal (sig=2,
>> handler=0x100163bc4 <handle_fatal_signal>) at sysdep.c:1654
>> #3 0x0000000100163bf6 in deliver_fatal_signal (sig=2) at sysdep.c:1720
>> #4 <signal handler called>
>> #5 0x00007fff87007b0a in timesub ()
>> #6 0x00007fff8700781c in _st_localsub ()
>> #7 0x00007fff87010d71 in localtime_r ()
>> #8 0x00000001002f5696 in localtime_rz (tz=0x101000f90,
>> t=0x7fff5fbf9498, tm=0x7fff5fbf93c0) at time_rz.c:296
>> #9 0x00000001001e3afd in emacs_localtime_rz (tz=0x101000f90,
>> t=0x7fff5fbf9498, tm=0x7fff5fbf93c0) at editfns.c:103
>> #10 0x00000001001e9746 in Fdecode_time (specified_time={i =
>> 4351999171}, zone={i = 0}) at editfns.c:2163
>> #11 0x000000010020183b in funcall_subr (subr=0x1007bcdd8, numargs=1,
>> args=0x7fff5fbf9608) at eval.c:2817
>> #12 0x000000010020133c in Ffuncall (nargs=2, args=0x7fff5fbf9600) at
>> eval.c:2740
>> #13 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399444},
>> vector={i = 4352860773}, maxdepth={i = 18}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbf9a08) at bytecode.c:629
>> #14 0x0000000100201fe7 in funcall_lambda (fun={i = 4352860813},
>> nargs=1, arg_vector=0x7fff5fbf9a00) at eval.c:2941
>> #15 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbf99f8) at
>> eval.c:2742
>> #16 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399380},
>> vector={i = 4352860677}, maxdepth={i = 42}, args_template={i = 3086},
>> nargs=3, args=0x7fff5fbf9e30) at bytecode.c:629
>> #17 0x0000000100201fe7 in funcall_lambda (fun={i = 4352860725},
>> nargs=3, arg_vector=0x7fff5fbf9e18) at eval.c:2941
>> #18 0x0000000100201374 in Ffuncall (nargs=4, args=0x7fff5fbf9e10) at
>> eval.c:2742
>> #19 0x000000010025ad5d in exec_byte_code (bytestr={i = 4333399348},
>> vector={i = 4352860861}, maxdepth={i = 46}, args_template={i = 0},
>> nargs=0, args=0x0) at bytecode.c:629
>> #20 0x0000000100259e7b in Fbyte_code (bytestr={i = 4333399348},
>> vector={i = 4352860861}, maxdepth={i = 46}) at bytecode.c:321
>> #21 0x00000001001ffac1 in eval_sub (form={i = 4352004051}) at
>> eval.c:2222
>> #22 0x00000001001fb503 in Fdefconst (args={i = 4352004099}) at
>> eval.c:809
>> #23 0x00000001001ff63a in eval_sub (form={i = 4352004115}) at
>> eval.c:2169
>> #24 0x0000000100239455 in readevalloop (readcharfun={i = 24096},
>> infile0=0x7fff5fbfa750, sourcename={i = 4330661364}, printflag=false,
>> unibyte={i = 0}, readfun={i = 0}, start={i = 0}, end={i = 0}) at
>> lread.c:2038
>> #25 0x0000000100237532 in Fload (file={i = 4331687524}, noerror={i =
>> 0}, nomessage={i = 45360}, nosuffix={i = 0}, must_suffix={i = 45360})
>> at lread.c:1425
>> #26 0x0000000100210444 in Frequire (feature={i = 42008288},
>> filename={i = 0}, noerror={i = 0}) at fns.c:2801
>> #27 0x000000010020186f in funcall_subr (subr=0x1007bed48, numargs=1,
>> args=0x7fff5fbfacd0) at eval.c:2820
>> #28 0x000000010020133c in Ffuncall (nargs=2, args=0x7fff5fbfacc8) at
>> eval.c:2740
>> #29 0x0000000100200087 in Fapply (nargs=2, args=0x7fff5fbfacc8) at
>> eval.c:2328
>> #30 0x00000001002016cc in funcall_subr (subr=0x1007bda88, numargs=2,
>> args=0x7fff5fbfacc8) at eval.c:2795
>> #31 0x000000010020133c in Ffuncall (nargs=3, args=0x7fff5fbfacc0) at
>> eval.c:2740
>> #32 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330679892},
>> vector={i = 4455527021}, maxdepth={i = 38}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfb138) at bytecode.c:629
>> #33 0x0000000100201fe7 in funcall_lambda (fun={i = 4455527189},
>> nargs=1, arg_vector=0x7fff5fbfb130) at eval.c:2941
>> #34 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb128) at
>> eval.c:2742
>> #35 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678964},
>> vector={i = 4455517957}, maxdepth={i = 18}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfb530) at bytecode.c:629
>> #36 0x0000000100201fe7 in funcall_lambda (fun={i = 4455518005},
>> nargs=1, arg_vector=0x7fff5fbfb528) at eval.c:2941
>> #37 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb520) at
>> eval.c:2742
>> #38 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678836},
>> vector={i = 4455517813}, maxdepth={i = 22}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfb918) at bytecode.c:629
>> #39 0x0000000100201fe7 in funcall_lambda (fun={i = 4455517861},
>> nargs=1, arg_vector=0x7fff5fbfb910) at eval.c:2941
>> #40 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfb908) at
>> eval.c:2742
>> #41 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330662116},
>> vector={i = 4455466989}, maxdepth={i = 42}, args_template={i = 2058},
>> nargs=2, args=0x7fff5fbfbd38) at bytecode.c:629
>> #42 0x0000000100201fe7 in funcall_lambda (fun={i = 4455467093},
>> nargs=2, arg_vector=0x7fff5fbfbd28) at eval.c:2941
>> #43 0x0000000100201374 in Ffuncall (nargs=3, args=0x7fff5fbfbd20) at
>> eval.c:2742
>> #44 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330678804},
>> vector={i = 4455495149}, maxdepth={i = 18}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfc108) at bytecode.c:629
>> #45 0x0000000100201fe7 in funcall_lambda (fun={i = 4455517909},
>> nargs=1, arg_vector=0x7fff5fbfc100) at eval.c:2941
>> #46 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfc0f8) at
>> eval.c:2742
>> #47 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330676260},
>> vector={i = 4455508293}, maxdepth={i = 42}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfc580) at bytecode.c:629
>> #48 0x0000000100201fe7 in funcall_lambda (fun={i = 4455508517},
>> nargs=1, arg_vector=0x7fff5fbfc578) at eval.c:2941
>> #49 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfc570) at
>> eval.c:2742
>> #50 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330676164},
>> vector={i = 4455512637}, maxdepth={i = 70}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfcad8) at bytecode.c:629
>> #51 0x0000000100201fe7 in funcall_lambda (fun={i = 4455508565},
>> nargs=1, arg_vector=0x7fff5fbfcad0) at eval.c:2941
>> #52 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfcac8) at
>> eval.c:2742
>> #53 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330675236},
>> vector={i = 4455503421}, maxdepth={i = 66}, args_template={i = 2054},
>> nargs=1, args=0x7fff5fbfd0a0) at bytecode.c:629
>> #54 0x0000000100201fe7 in funcall_lambda (fun={i = 4455504133},
>> nargs=1, arg_vector=0x7fff5fbfd098) at eval.c:2941
>> #55 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfd090) at
>> eval.c:2742
>> #56 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330698708},
>> vector={i = 4455656013}, maxdepth={i = 34}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfd4f8) at bytecode.c:629
>> #57 0x0000000100201fe7 in funcall_lambda (fun={i = 4455647189},
>> nargs=1, arg_vector=0x7fff5fbfd4f0) at eval.c:2941
>> #58 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfd4e8) at
>> eval.c:2742
>> #59 0x000000010025ad5d in exec_byte_code (bytestr={i = 4330698612},
>> vector={i = 4455660765}, maxdepth={i = 42}, args_template={i = 1026},
>> nargs=0, args=0x7fff5fbfd9e8) at bytecode.c:629
>> #60 0x0000000100201fe7 in funcall_lambda (fun={i = 4455647141},
>> nargs=0, arg_vector=0x7fff5fbfd9e8) at eval.c:2941
>> #61 0x0000000100201374 in Ffuncall (nargs=1, args=0x7fff5fbfd9e0) at
>> eval.c:2742
>> #62 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299934692},
>> vector={i = 4299934725}, maxdepth={i = 94}, args_template={i = 1030},
>> nargs=1, args=0x7fff5fbfe288) at bytecode.c:629
>> #63 0x0000000100201fe7 in funcall_lambda (fun={i = 4299934645},
>> nargs=1, arg_vector=0x7fff5fbfe280) at eval.c:2941
>> #64 0x0000000100201374 in Ffuncall (nargs=2, args=0x7fff5fbfe278) at
>> eval.c:2742
>> #65 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299912628},
>> vector={i = 4299912661}, maxdepth={i = 86}, args_template={i = 2},
>> nargs=0, args=0x7fff5fbfedb8) at bytecode.c:629
>> #66 0x0000000100201fe7 in funcall_lambda (fun={i = 4299912581},
>> nargs=0, arg_vector=0x7fff5fbfedb8) at eval.c:2941
>> #67 0x0000000100201374 in Ffuncall (nargs=1, args=0x7fff5fbfedb0) at
>> eval.c:2742
>> #68 0x000000010025ad5d in exec_byte_code (bytestr={i = 4299908964},
>> vector={i = 4299908997}, maxdepth={i = 50}, args_template={i = 2},
>> nargs=0, args=0x7fff5fbff2f0) at bytecode.c:629
>> #69 0x0000000100201fe7 in funcall_lambda (fun={i = 4299908917},
>> nargs=0, arg_vector=0x7fff5fbff2f0) at eval.c:2941
>> #70 0x0000000100201c16 in apply_lambda (fun={i = 4299908917}, args={i
>> = 0}, count=4) at eval.c:2877
>> #71 0x00000001001ffc89 in eval_sub (form={i = 4379235827}) at
>> eval.c:2261
>> #72 0x00000001001fef96 in Feval (form={i = 4379235827}, lexical={i =
>> 0}) at eval.c:2038
>> #73 0x0000000100139c2c in top_level_2 () at keyboard.c:1123
>> #74 0x00000001001fd0d8 in internal_condition_case (bfun=0x100139c08
>> <top_level_2>, handlers={i = 18528}, hfun=0x100139519 <cmd_error>) at
>> eval.c:1319
>> #75 0x0000000100139c78 in top_level_1 (ignore={i = 0}) at
>> keyboard.c:1131
>> #76 0x00000001001fc551 in internal_catch (tag={i = 46944},
>> func=0x100139c2e <top_level_1>, arg={i = 0}) at eval.c:1084
>> #77 0x0000000100139b4d in command_loop () at keyboard.c:1092
>> #78 0x0000000100138fb0 in recursive_edit_1 () at keyboard.c:699
>> #79 0x00000001001391c7 in Frecursive_edit () at keyboard.c:770
>> #80 0x0000000100136cdc in main (argc=9, argv=0x7fff5fbff8e8) at
>> emacs.c:1706
>>
>> Lisp Backtrace:
>> "decode-time" (0x5fbf9608)
>> 0x3736288 PVEC_COMPILED
>> 0x3736230 PVEC_COMPILED
>> "byte-code" (0x5fbfa140)
>> "defconst" (0x5fbfa3e0)
>> "require" (0x5fbfacd0)
>> "apply" (0x5fbfacc8)
>> "byte-compile-file-form-require" (0x5fbfb130)
>> "byte-compile-file-form" (0x5fbfb528)
>> 0x991cea0 PVEC_COMPILED
>> "byte-compile-recurse-toplevel" (0x5fbfbd28)
>> "byte-compile-toplevel-file-form" (0x5fbfc100)
>> 0x991aa20 PVEC_COMPILED
>> "byte-compile-from-buffer" (0x5fbfcad0)
>> "byte-compile-file" (0x5fbfd098)
>> "batch-byte-compile-file" (0x5fbfd4f0)
>> "batch-byte-compile" (0x5fbfd9e8)
>> "command-line-1" (0x5fbfe280)
>> "command-line" (0x5fbfedb8)
>> "normal-top-level" (0x5fbff2f0)
>> (gdb) select 5
>> (gdb) frame 5
>> #5 0x00007fff87007b0a in timesub ()
>> (gdb) frame 10
>> #10 0x00000001001e9746 in Fdecode_time (specified_time={i =
>> 4351999171}, zone={i = 0}) at editfns.c:2163
>> 2163 struct tm *tm = emacs_localtime_rz (tz, &time_spec,
>> &local_tm);
>> (gdb) pp specified_time
>> (-1034058203136 0)
>> (gdb)
>
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-19 19:58 ` Charles A. Roelli
@ 2017-07-19 22:48 ` Alan Third
2017-07-23 9:28 ` Charles A. Roelli
0 siblings, 1 reply; 39+ messages in thread
From: Alan Third @ 2017-07-19 22:48 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: Keith David Bershatsky, 27736, Noam Postavsky
On Wed, Jul 19, 2017 at 09:58:03PM +0200, Charles A. Roelli wrote:
> Err, oops: I guess there will be no patch for this in Lisp, since
> decode-time is written in C.
>
>
> So the choice is either to make a change in lib/time_rz.c or src/editfns.c.
Do you know what the actual problem is? If it’s going into an infinite
loop, why is that happening? That might give us a better idea where
the fix should go.
--
Alan Third
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-19 22:48 ` Alan Third
@ 2017-07-23 9:28 ` Charles A. Roelli
2017-07-24 15:50 ` Glenn Morris
0 siblings, 1 reply; 39+ messages in thread
From: Charles A. Roelli @ 2017-07-23 9:28 UTC (permalink / raw)
To: Alan Third; +Cc: Keith David Bershatsky, 27736, Noam Postavsky
I have no idea why the code goes into an infinite loop, but it seems
somebody else has already had the same problem (on FreeBSD, the source
of Apple's libc):
https://rt.cpan.org/Public/Bug/Display.html?id=40764
They have a freeze on the same value of "time" that we have:
(gdb) frame 4
#4 0x00000001002b9d8b in emacs_localtime_rz (tz=0x102102a60,
t=0x7fff5fbe8b80, tm=0x7fff5fbe8b48) at editfns.c:103
103 tm = localtime_rz (tz, t, tm);
(gdb) ptype t
type = long *
(gdb) p *t
$2 = -67768038400720896
Somebody in the linked thread also had the same problem on macOS. And
apparently NetBSD had some of the same issues (search for "infinite
loop in localtime" on the linked page):
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/localtime.c?only_with_tag=MAIN
But I'm not sure those fixes would have anything to do with macOS.
On 20/07/2017 00:48, Alan Third wrote:
> On Wed, Jul 19, 2017 at 09:58:03PM +0200, Charles A. Roelli wrote:
>> Err, oops: I guess there will be no patch for this in Lisp, since
>> decode-time is written in C.
>>
>>
>> So the choice is either to make a change in lib/time_rz.c or src/editfns.c.
> Do you know what the actual problem is? If it’s going into an infinite
> loop, why is that happening? That might give us a better idea where
> the fix should go.
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (6 preceding siblings ...)
2017-07-18 16:07 ` Keith David Bershatsky
@ 2017-11-05 18:03 ` Keith David Bershatsky
2017-11-05 18:15 ` Noam Postavsky
2017-11-05 20:01 ` Keith David Bershatsky
` (4 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-11-05 18:03 UTC (permalink / raw)
To: 27736
[-- Attachment #1: Type: text/plain, Size: 65 bytes --]
;;;;;;;;;;;;;;;;;;;;;; FORWARDED MESSAGE ;;;;;;;;;;;;;;;;;;;;;;
[-- Attachment #2: Type: message/rfc822, Size: 1054 bytes --]
From: Keith David Bershatsky <esq@lawlist.com>
To: 27736@debbugs.gnu.org
Cc: "Charles A. Roelli" <charles@aurox.ch>,Alan Third <alan@idiocy.org>,Noam Postavsky <npostavs@users.sourceforge.net>, Eli Zaretskii <eliz@gnu.org>
Subject: Re: bug#27736: OSX 10.6.8: Building from master branch fails.
Date: Sun, 05 Nov 2017 09:14:56 -0800
Message-ID: <m2a800ve9b.wl%esq@lawlist.com>
I realize that this bug was closed some time ago and I apologize for not speaking up sooner. I am still unable to build current versions of Emacs 26 or the master branch on OSX 10.6.8 (server edition) absent using an earlier version of org-mode.
The same symptoms as described in the initial bug report still persist -- i.e., build freezes when byte-compiling org-timer.el:
ELC org/org-timer.elc
For those who have reported that the previous attempted fix was successful, perhaps there is a difference between retail OSX 10.6.8 and the server edition. But, that's just a guess on my part.
Thanks,
Keith
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-11-05 18:03 ` Keith David Bershatsky
@ 2017-11-05 18:15 ` Noam Postavsky
0 siblings, 0 replies; 39+ messages in thread
From: Noam Postavsky @ 2017-11-05 18:15 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
Keith David Bershatsky <esq@lawlist.com> writes:
> The same symptoms as described in the initial bug report still persist -- i.e., build freezes when byte-compiling org-timer.el:
>
> ELC org/org-timer.elc
>
> For those who have reported that the previous attempted fix was
> successful, perhaps there is a difference between retail OSX 10.6.8
> and the server edition. But, that's just a guess on my part.
Based on the fix which is posted here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27706#25
I think the output of
(shell-command-to-string "sw_vers -productVersion")
on your machine would be of interest.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (7 preceding siblings ...)
2017-11-05 18:03 ` Keith David Bershatsky
@ 2017-11-05 20:01 ` Keith David Bershatsky
2017-11-06 2:20 ` Keith David Bershatsky
` (3 subsequent siblings)
12 siblings, 0 replies; 39+ messages in thread
From: Keith David Bershatsky @ 2017-11-05 20:01 UTC (permalink / raw)
To: Noam Postavsky; +Cc: 27736
Just plain old "10.6.8" is returned:
(shell-command-to-string "sw_vers -productVersion"): "10.6.8"
Here is a copy of the System Profiler / System Software Overview:
System Version: Mac OS X Server 10.6.8 (10K549)
Server Configuration: Advanced
Kernel Version: Darwin 10.8.0
Boot Volume: SERVER
Boot Mode: Normal
Computer Name: server
User Name: lawlist (HOME)
Secure Virtual Memory: Not Enabled
64-bit Kernel and Extensions: Yes
Time since boot: 3:28
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [11-05-2017 10:15:45] <05 Nov 2017 13:15:45 -0500>
FROM: Noam Postavsky <npostavs@users.sourceforge.net>
>
> * * *
>
> Based on the fix which is posted here:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27706#25
>
> I think the output of
>
> (shell-command-to-string "sw_vers -productVersion")
>
> on your machine would be of interest.
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (8 preceding siblings ...)
2017-11-05 20:01 ` Keith David Bershatsky
@ 2017-11-06 2:20 ` Keith David Bershatsky
2017-11-06 19:41 ` Charles A. Roelli
2017-11-07 2:13 ` Keith David Bershatsky
` (2 subsequent siblings)
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-11-06 2:20 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: Alan Third, 27736, Noam Postavsky
Here is the backtrace using the master branch downloaded this evening (11/05/2017). `pp specified_time` result is located at the end of the backtrace.
server:src HOME$ /Users/HOME/.0.data/.0.emacs/.0.macports/bin/ggdb /Users/HOME/Desktop/emacs/src/emacs
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10.8.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /Users/HOME/Desktop/emacs/src/emacs...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = /tmp/launch-7r8Xmk/org.x:0
TERM = xterm-color
Breakpoint 1 at 0x100136006: file emacs.c, line 364.
Temporary breakpoint 2 at 0x1001640d8: file sysdep.c, line 1071.
(gdb) run -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
Starting program: /Users/HOME/Desktop/emacs/src/emacs -batch --no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -f batch-byte-compile /Users/HOME/Desktop/emacs/lisp/org/org-timer.el
[New Thread 0x1903 of process 74928]
[New Thread 0x1a03 of process 74928]
^C
Breakpoint 1, terminate_due_to_signal (sig=2, backtrace_limit=40)
at emacs.c:364
364 signal (sig, SIG_DFL);
(gdb) bt
#0 terminate_due_to_signal (sig=2, backtrace_limit=40) at emacs.c:364
#1 0x000000010016542b in handle_fatal_signal (sig=2) at sysdep.c:1769
#2 0x000000010016535f in deliver_process_signal (sig=2,
handler=0x100165413 <handle_fatal_signal>) at sysdep.c:1709
#3 0x0000000100165445 in deliver_fatal_signal (sig=2) at sysdep.c:1775
#4 0x00007fff870231ba in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#5 0x00007fff87007aac in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#6 0x00007fff8700781c in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#7 0x00007fff87010d71 in cidToUnicode_CNS1 () from /usr/lib/libSystem.B.dylib
#8 0x00000001002f8e00 in localtime_rz (tz=0x101109930, t=0x7fff5fbf93d8,
tm=0x7fff5fbf9300) at time_rz.c:296
#9 0x00000001001e58c9 in emacs_localtime_rz (tz=0x101109930,
t=0x7fff5fbf93d8, tm=0x7fff5fbf9300) at editfns.c:103
#10 0x00000001001eb594 in Fdecode_time (specified_time=XIL(0x1065cca73),
zone=XIL(0)) at editfns.c:2165
#11 0x0000000100203bff in funcall_subr (subr=0x1007c2008 <Sdecode_time>,
numargs=1, args=0x7fff5fbf9548) at eval.c:2844
#12 0x0000000100203700 in Ffuncall (nargs=2, args=0x7fff5fbf9540)
at eval.c:2767
#13 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x102070104),
vector=XIL(0x10658aa75), maxdepth=make_number(8),
args_template=make_number(257), nargs=1, args=0x7fff5fbf9988)
at bytecode.c:629
#14 0x00000001002043ab in funcall_lambda (fun=XIL(0x10658aae5), nargs=1,
arg_vector=0x7fff5fbf9980) at eval.c:2968
#15 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbf9978)
at eval.c:2769
#16 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1020700c4),
vector=XIL(0x10658aa15), maxdepth=make_number(10),
args_template=make_number(771), nargs=3, args=0x7fff5fbf9db0)
at bytecode.c:629
#17 0x00000001002043ab in funcall_lambda (fun=XIL(0x10658aa45), nargs=3,
arg_vector=0x7fff5fbf9d98) at eval.c:2968
#18 0x0000000100203738 in Ffuncall (nargs=4, args=0x7fff5fbf9d90)
at eval.c:2769
#19 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1020700a4),
vector=XIL(0x10658ab35), maxdepth=make_number(11), args_template=XIL(0),
nargs=0, args=0x0) at bytecode.c:629
#20 0x000000010025c59f in Fbyte_code (bytestr=XIL(0x1020700a4),
vector=XIL(0x10658ab35), maxdepth=make_number(11)) at bytecode.c:321
#21 0x0000000100201e0d in eval_sub (form=XIL(0x1065c4873)) at eval.c:2238
#22 0x00000001001fd7ad in Fdefconst (args=XIL(0x1065c4883)) at eval.c:817
#23 0x000000010020190c in eval_sub (form=XIL(0x1065c4893)) at eval.c:2184
#24 0x000000010023b925 in readevalloop (readcharfun=XIL(0x5ee0),
infile0=0x7fff5fbfa6e0, sourcename=XIL(0x102c6518c), printflag=false,
unibyte=XIL(0), readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2038
#25 0x0000000100239a02 in Fload (file=XIL(0x102c778fc), noerror=XIL(0),
nomessage=XIL(0xb3a0), nosuffix=XIL(0), must_suffix=XIL(0xb3a0))
at lread.c:1425
#26 0x00000001002128b8 in Frequire (feature=XIL(0x703d600), filename=XIL(0),
noerror=XIL(0)) at fns.c:2807
#27 0x0000000100203c33 in funcall_subr (subr=0x1007c3f68 <Srequire>,
numargs=1, args=0x7fff5fbfac60) at eval.c:2847
#28 0x0000000100203700 in Ffuncall (nargs=2, args=0x7fff5fbfac58)
at eval.c:2767
#29 0x00000001002023d3 in Fapply (nargs=2, args=0x7fff5fbfac58) at eval.c:2344
#30 0x0000000100203a90 in funcall_subr (subr=0x1007c2ca8 <Sapply>, numargs=2,
args=0x7fff5fbfac58) at eval.c:2822
---Type <return> to continue, or q <return> to quit---
#31 0x0000000100203700 in Ffuncall (nargs=3, args=0x7fff5fbfac50)
at eval.c:2767
#32 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1011276b4),
vector=XIL(0x107115e6d), maxdepth=make_number(9),
args_template=make_number(257), nargs=1, args=0x7fff5fbfb0c8)
at bytecode.c:629
#33 0x00000001002043ab in funcall_lambda (fun=XIL(0x107115f1d), nargs=1,
arg_vector=0x7fff5fbfb0c0) at eval.c:2968
#34 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfb0b8)
at eval.c:2769
#35 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x101127414),
vector=XIL(0x107114e9d), maxdepth=make_number(4),
args_template=make_number(257), nargs=1, args=0x7fff5fbfb4c0)
at bytecode.c:629
#36 0x00000001002043ab in funcall_lambda (fun=XIL(0x107114ecd), nargs=1,
arg_vector=0x7fff5fbfb4b8) at eval.c:2968
#37 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfb4b0)
at eval.c:2769
#38 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1011273b4),
vector=XIL(0x1071141cd), maxdepth=make_number(5),
args_template=make_number(257), nargs=1, args=0x7fff5fbfb8a8)
at bytecode.c:629
#39 0x00000001002043ab in funcall_lambda (fun=XIL(0x107114e3d), nargs=1,
arg_vector=0x7fff5fbfb8a0) at eval.c:2968
#40 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfb898)
at eval.c:2769
#41 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x101123524),
vector=XIL(0x107107eed), maxdepth=make_number(10),
args_template=make_number(514), nargs=2, args=0x7fff5fbfbcc8)
at bytecode.c:629
#42 0x00000001002043ab in funcall_lambda (fun=XIL(0x107107f5d), nargs=2,
arg_vector=0x7fff5fbfbcb8) at eval.c:2968
#43 0x0000000100203738 in Ffuncall (nargs=3, args=0x7fff5fbfbcb0)
at eval.c:2769
#44 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x101127394),
vector=XIL(0x1071121dd), maxdepth=make_number(4),
args_template=make_number(257), nargs=1, args=0x7fff5fbfc098)
at bytecode.c:629
#45 0x00000001002043ab in funcall_lambda (fun=XIL(0x107114e6d), nargs=1,
arg_vector=0x7fff5fbfc090) at eval.c:2968
#46 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfc088)
at eval.c:2769
#47 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1011269e4),
vector=XIL(0x10711203d), maxdepth=make_number(10),
args_template=make_number(257), nargs=1, args=0x7fff5fbfc510)
at bytecode.c:629
#48 0x00000001002043ab in funcall_lambda (fun=XIL(0x10711211d), nargs=1,
arg_vector=0x7fff5fbfc508) at eval.c:2968
#49 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfc500)
at eval.c:2769
#50 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x101126984),
vector=XIL(0x107112e3d), maxdepth=make_number(17),
args_template=make_number(257), nargs=1, args=0x7fff5fbfca68)
at bytecode.c:629
#51 0x00000001002043ab in funcall_lambda (fun=XIL(0x10711214d), nargs=1,
arg_vector=0x7fff5fbfca60) at eval.c:2968
#52 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfca58)
at eval.c:2769
---Type <return> to continue, or q <return> to quit---
#53 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1011265e4),
vector=XIL(0x107110e7d), maxdepth=make_number(18),
args_template=make_number(513), nargs=1, args=0x7fff5fbfd060)
at bytecode.c:629
#54 0x00000001002043ab in funcall_lambda (fun=XIL(0x1071111bd), nargs=1,
arg_vector=0x7fff5fbfd058) at eval.c:2968
#55 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfd050)
at eval.c:2769
#56 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x10112b5f4),
vector=XIL(0x1071310dd), maxdepth=make_number(8),
args_template=make_number(257), nargs=1, args=0x7fff5fbfd4b8)
at bytecode.c:629
#57 0x00000001002043ab in funcall_lambda (fun=XIL(0x10712d1cd), nargs=1,
arg_vector=0x7fff5fbfd4b0) at eval.c:2968
#58 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfd4a8)
at eval.c:2769
#59 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x10112b594),
vector=XIL(0x1071340dd), maxdepth=make_number(10),
args_template=make_number(256), nargs=0, args=0x7fff5fbfd9a8)
at bytecode.c:629
#60 0x00000001002043ab in funcall_lambda (fun=XIL(0x10712d19d), nargs=0,
arg_vector=0x7fff5fbfd9a8) at eval.c:2968
#61 0x0000000100203738 in Ffuncall (nargs=1, args=0x7fff5fbfd9a0)
at eval.c:2769
#62 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1004c5f7c),
vector=XIL(0x1004c5f9d), maxdepth=make_number(23),
args_template=make_number(257), nargs=1, args=0x7fff5fbfe248)
at bytecode.c:629
#63 0x00000001002043ab in funcall_lambda (fun=XIL(0x1004c5f4d), nargs=1,
arg_vector=0x7fff5fbfe240) at eval.c:2968
#64 0x0000000100203738 in Ffuncall (nargs=2, args=0x7fff5fbfe238)
at eval.c:2769
#65 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1004c0744),
vector=XIL(0x1004c0765), maxdepth=make_number(21),
args_template=make_number(0), nargs=0, args=0x7fff5fbfed78)
at bytecode.c:629
#66 0x00000001002043ab in funcall_lambda (fun=XIL(0x1004c0715), nargs=0,
arg_vector=0x7fff5fbfed78) at eval.c:2968
#67 0x0000000100203738 in Ffuncall (nargs=1, args=0x7fff5fbfed70)
at eval.c:2769
#68 0x000000010025d481 in exec_byte_code (bytestr=XIL(0x1004bf934),
vector=XIL(0x1004bf955), maxdepth=make_number(12),
args_template=make_number(0), nargs=0, args=0x7fff5fbff2b0)
at bytecode.c:629
#69 0x00000001002043ab in funcall_lambda (fun=XIL(0x1004bf905), nargs=0,
arg_vector=0x7fff5fbff2b0) at eval.c:2968
#70 0x0000000100203fda in apply_lambda (fun=XIL(0x1004bf905), args=XIL(0),
count=4) at eval.c:2904
#71 0x0000000100201fd5 in eval_sub (form=XIL(0x104139273)) at eval.c:2277
#72 0x000000010020125f in Feval (form=XIL(0x104139273), lexical=XIL(0))
at eval.c:2052
#73 0x000000010013afe0 in top_level_2 () at keyboard.c:1119
#74 0x00000001001ff34a in internal_condition_case (
bfun=0x10013afbc <top_level_2>, handlers=XIL(0x48f0),
hfun=0x10013a8cd <cmd_error>) at eval.c:1332
#75 0x000000010013b02c in top_level_1 (ignore=XIL(0)) at keyboard.c:1127
#76 0x00000001001fe7c3 in internal_catch (tag=XIL(0xb9d0),
func=0x10013afe2 <top_level_1>, arg=XIL(0)) at eval.c:1097
---Type <return> to continue, or q <return> to quit---
#77 0x000000010013af01 in command_loop () at keyboard.c:1088
#78 0x000000010013a364 in recursive_edit_1 () at keyboard.c:695
#79 0x000000010013a57b in Frecursive_edit () at keyboard.c:766
#80 0x0000000100138090 in main (argc=9, argv=0x7fff5fbff8b0) at emacs.c:1711
[New Thread 0x1a07 of process 74928]
Lisp Backtrace:
"decode-time" (0x5fbf9548)
0x658aae0 PVEC_COMPILED
0x658aa40 PVEC_COMPILED
"byte-code" (0x5fbfa0c0)
"defconst" (0x5fbfa370)
"require" (0x5fbfac60)
"apply" (0x5fbfac58)
"byte-compile-file-form-require" (0x5fbfb0c0)
"byte-compile-file-form" (0x5fbfb4b8)
0x7114e38 PVEC_COMPILED
"byte-compile-recurse-toplevel" (0x5fbfbcb8)
"byte-compile-toplevel-file-form" (0x5fbfc090)
0x7112118 PVEC_COMPILED
"byte-compile-from-buffer" (0x5fbfca60)
"byte-compile-file" (0x5fbfd058)
"batch-byte-compile-file" (0x5fbfd4b0)
"batch-byte-compile" (0x5fbfd9a8)
"command-line-1" (0x5fbfe240)
"command-line" (0x5fbfed78)
"normal-top-level" (0x5fbff2b0)
(gdb) frame 10
#10 0x00000001001eb594 in Fdecode_time (specified_time=XIL(0x1065cca73),
zone=XIL(0)) at editfns.c:2165
2165 struct tm *tm = emacs_localtime_rz (tz, &time_spec, &local_tm);
(gdb) pp specified_time
(-1034058203135 0)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [11-05-2017 12:54:19] <5 Nov 2017 21:54:19 +0100>
FROM: "Charles A. Roelli" <charles@aurox.ch>
>
> Could you please show a backtrace as posted here:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27736#49
>
> * * *
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-11-06 2:20 ` Keith David Bershatsky
@ 2017-11-06 19:41 ` Charles A. Roelli
2017-11-06 20:41 ` Charles A. Roelli
0 siblings, 1 reply; 39+ messages in thread
From: Charles A. Roelli @ 2017-11-06 19:41 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: alan, 27736, npostavs
> (gdb) pp specified_time
>
> (-1034058203135 0)
Thanks. I think the timezone of the compiling machine changes which
arguments are safe to pass to `decode-time' on old macOSen. I
previously wrote some programs to zero in on the bad values here:
https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00140.html
and here:
https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00142.html
[time_find.c and time_search.c]
Could you try to run them (changing the constants TIME_CHECK_DELTA and
TIME_CHECK_RANGE in time_find.c, and TIME_CHECK_GOOD and
TIME_CHECK_BAD in time_search.c as necessary)? It is simplest to
compile them in the same directory as gnulib, which is located in the
lib/ folder of emacs, as they expct gnulib's "time.h".
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-11-06 19:41 ` Charles A. Roelli
@ 2017-11-06 20:41 ` Charles A. Roelli
0 siblings, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2017-11-06 20:41 UTC (permalink / raw)
To: esq; +Cc: alan, 27736, npostavs
> Date: Mon, 06 Nov 2017 20:41:43 +0100
> From: charles@aurox.ch (Charles A. Roelli)
>
> > (gdb) pp specified_time
> >
> > (-1034058203135 0)
>
> Thanks. I think the timezone of the compiling machine changes which
> arguments are safe to pass to `decode-time' on old macOSen. I
> previously wrote some programs to zero in on the bad values here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00140.html
>
> and here:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00142.html
>
> [time_find.c and time_search.c]
>
> Could you try to run them (changing the constants TIME_CHECK_DELTA and
> TIME_CHECK_RANGE in time_find.c, and TIME_CHECK_GOOD and
> TIME_CHECK_BAD in time_search.c as necessary)? It is simplest to
> compile them in the same directory as gnulib, which is located in the
> lib/ folder of emacs, as they expct gnulib's "time.h".
Actually, I just tried the programs myself after switching to a
western time zone, leading to this small local change:
--- a/lisp/org/org-clock.el
+++ b/lisp/org/org-clock.el
@@ -487,7 +487,7 @@ org-clock--oldest-date
"10\\.6\\.[[:digit:]]"
(shell-command-to-string
"sw_vers -productVersion"))
- (<= m -1034058203136))
+ (<= m -1034058203135))
(ignore-errors (decode-time (list m 0)))))))
(low
(funcall dichotomy
Does it fix the compilation for you?
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (9 preceding siblings ...)
2017-11-06 2:20 ` Keith David Bershatsky
@ 2017-11-07 2:13 ` Keith David Bershatsky
2017-11-07 20:20 ` Charles A. Roelli
2017-11-08 5:18 ` Keith David Bershatsky
2018-03-27 21:19 ` Paul Eggert
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-11-07 2:13 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: Alan Third, 27736, Noam Postavsky
Thank you Charles for working on this issue. I was able to byte-compile org-timer.el successfully by using the following inside of org-clock.el at the same location you indicated:
(or
(<= m -1034058203136)
(<= m -1034058203135))
I tried a few times with just (<= m -1034058203135), and it was not enough -- i.e., I was unable to byte-compile using only (<= m -1034058203135).
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [11-06-2017 12:41:28] <06 Nov 2017 09:41:28 -1100>
FROM: charles@aurox.ch (Charles A. Roelli)
>
> > Date: Mon, 06 Nov 2017 20:41:43 +0100
> > From: charles@aurox.ch (Charles A. Roelli)
> >
> > > (gdb) pp specified_time
> > >
> > > (-1034058203135 0)
> >
> > * * *
>
>
> --- a/lisp/org/org-clock.el
> +++ b/lisp/org/org-clock.el
> @@ -487,7 +487,7 @@ org-clock--oldest-date
> "10\\.6\\.[[:digit:]]"
> (shell-command-to-string
> "sw_vers -productVersion"))
> - (<= m -1034058203136))
> + (<= m -1034058203135))
> (ignore-errors (decode-time (list m 0)))))))
> (low
> (funcall dichotomy
>
> Does it fix the compilation for you?
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-11-07 2:13 ` Keith David Bershatsky
@ 2017-11-07 20:20 ` Charles A. Roelli
0 siblings, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2017-11-07 20:20 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
> Date: Mon, 06 Nov 2017 18:13:28 -0800
> From: Keith David Bershatsky <esq@lawlist.com>
>
> Thank you Charles for working on this issue. I was able to byte-compile org-timer.el successfully by using the following inside of org-clock.el at the same location you indicated:
>
> (or
> (<= m -1034058203136)
> (<= m -1034058203135))
>
> I tried a few times with just (<= m -1034058203135), and it was not enough -- i.e., I was unable to byte-compile using only (<= m -1034058203135).
>
> Keith
That's odd. Compiling worked fine for me on any timezone with:
rm -f lisp/org/org-{clock,timer}.elc && make
Can you try again, and if it still does not work, show a backtrace as
before using just (<= m -1034058203135)? Thanks for your patience.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (10 preceding siblings ...)
2017-11-07 2:13 ` Keith David Bershatsky
@ 2017-11-08 5:18 ` Keith David Bershatsky
2017-11-08 19:55 ` Charles A. Roelli
2018-03-27 21:19 ` Paul Eggert
12 siblings, 1 reply; 39+ messages in thread
From: Keith David Bershatsky @ 2017-11-08 5:18 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: 27736
Today, I went back in time using my saved undo history, but was unable to locate having tried a saved version of the file that used only (<= m -1034058203135). What I found was a typographical error ... containing an extra digit.
I tried it tonight using only (<= m -1034058203135) and it is working. So, I must assume that the error was on my end. The saved undo history doesn't lie. :)
Yes, let's go with just (<= m -1034058203135).
I apologize for the wild goose chase.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [11-07-2017 12:20:39] <07 Nov 2017 21:20:39 +0100>
FROM: charles@aurox.ch (Charles A. Roelli)
>
> > Date: Mon, 06 Nov 2017 18:13:28 -0800
> > From: Keith David Bershatsky <esq@lawlist.com>
> >
> > Thank you Charles for working on this issue. I was able to byte-compile org-timer.el successfully by using the following inside of org-clock.el at the same location you indicated:
> >
> > (or
> > (<= m -1034058203136)
> > (<= m -1034058203135))
> >
> > I tried a few times with just (<= m -1034058203135), and it was not enough -- i.e., I was unable to byte-compile using only (<= m -1034058203135).
> >
> > Keith
>
> That's odd. Compiling worked fine for me on any timezone with:
>
> rm -f lisp/org/org-{clock,timer}.elc && make
>
> Can you try again, and if it still does not work, show a backtrace as
> before using just (<= m -1034058203135)? Thanks for your patience.
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-11-08 5:18 ` Keith David Bershatsky
@ 2017-11-08 19:55 ` Charles A. Roelli
0 siblings, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2017-11-08 19:55 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 27736
No worries. The fix is pushed to emacs-26, and it should make it over
to the master branch soon.
commit 98288ecaffbc0947ec3193088172ea85ad5e42a5
Author: Charles A. Roelli <charles@aurox.ch>
Ref: emacs-26
Date: Wed Nov 8 20:51:48 2017 +0100
Further workaround for faulty localtime() under macOS 10.6
* lisp/org/org-clock.el (org-clock--oldest-date): Fix an issue
when compiling on macOS 10.6 with a western time zone (a
continuation of Bug#27736). In particular, see:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27736#74
and the first commit that attempted to work around this problem,
"Workaround for faulty localtime() under macOS 10.6", bd49b6f1 of
2017-09-30.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2017-07-17 15:18 bug#27736: OSX 10.6.8: Building from master branch fails Keith David Bershatsky
` (11 preceding siblings ...)
2017-11-08 5:18 ` Keith David Bershatsky
@ 2018-03-27 21:19 ` Paul Eggert
2018-03-28 17:15 ` Glenn Morris
2018-03-28 18:54 ` Charles A. Roelli
12 siblings, 2 replies; 39+ messages in thread
From: Paul Eggert @ 2018-03-27 21:19 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: Keith David Bershatsky, 27736, Noam Postavsky
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
> > (<= m -1034058203136)
> > (<= m -1034058203135))
Unfortunately these numbers don't fit into a 30-bit integer and so they
run afoul of a portability issue, namely, that files byte-compiled on a
64-bit Emacs should run on a 32-bit Emacs and vice versa. I noticed this
problem when preparing a patch to catch this sort of issue. To fix this
particular instance of the problem, I attempted to migrate the localtime
workaround into editfns.c (so that the fix is more-general, and is not
limited to org-clock), by installing the attached patches into master.
Please give them a try, since I don't have easy access to Mac OS X. I'm
still a bit fuzzy on exactly which timestamps cause Mac OS X localtime
to go belly-up (is it timezone dependent?), so quite possibly the magic
numbers in these patches need to be adjusted a bit so that the code will
work in any timezone from TZ=AAA-24:59:59 to TZ=ZZZ24:59:59; please let
me know.
[-- Attachment #2: 0001-Update-from-Gnulib.patch --]
[-- Type: text/x-patch, Size: 3982 bytes --]
From 72fad885b68617db85901a8e810211b557a31f99 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 27 Mar 2018 13:30:50 -0700
Subject: [PATCH 1/2] Update from Gnulib
This incorporates:
2018-03-26 time_rz: work around Mac OS X 10.6 infloop
2018-03-20 euidaccess: Port to native Windows.
* lib/euidaccess.c, lib/time_rz.c, m4/time_rz.m4: Copy from Gnulib.
---
lib/euidaccess.c | 11 ++++++++---
lib/time_rz.c | 15 +++++++++++++++
m4/time_rz.m4 | 32 ++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/lib/euidaccess.c b/lib/euidaccess.c
index aee693571c..4f512f5af5 100644
--- a/lib/euidaccess.c
+++ b/lib/euidaccess.c
@@ -29,8 +29,11 @@
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
-
-#include "root-uid.h"
+#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+# include <io.h>
+#else
+# include "root-uid.h"
+#endif
#if HAVE_LIBGEN_H
# include <libgen.h>
@@ -84,7 +87,9 @@ euidaccess (const char *file, int mode)
return accessx (file, mode, ACC_SELF);
#elif HAVE_EACCESS /* FreeBSD */
return eaccess (file, mode);
-#else /* Mac OS X, NetBSD, OpenBSD, HP-UX, Solaris, Cygwin, mingw, BeOS */
+#elif (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__ /* mingw */
+ return _access (file, mode);
+#else /* Mac OS X, NetBSD, OpenBSD, HP-UX, Solaris, Cygwin, BeOS */
uid_t uid = getuid ();
gid_t gid = getgid ();
diff --git a/lib/time_rz.c b/lib/time_rz.c
index c1eca888f2..5293c7cf8d 100644
--- a/lib/time_rz.c
+++ b/lib/time_rz.c
@@ -286,6 +286,21 @@ revert_tz (timezone_t tz)
struct tm *
localtime_rz (timezone_t tz, time_t const *t, struct tm *tm)
{
+#ifdef HAVE_LOCALTIME_INFLOOP_BUG
+ /* The -67768038400665599 comes from:
+ https://lists.gnu.org/r/bug-gnulib/2017-07/msg00142.html
+ On affected platforms the greatest POSIX-compatible time_t value
+ that could return nonnull is 67768036191766798 (when
+ TZ="XXX24:59:59" it resolves to the year 2**31 - 1 + 1900, on
+ 12-31 at 23:59:59), so test for that too while we're in the
+ neighborhood. */
+ if (! (-67768038400665599 <= *t && *t <= 67768036191766798))
+ {
+ errno = EOVERFLOW;
+ return NULL;
+ }
+#endif
+
if (!tz)
return gmtime_r (t, tm);
else
diff --git a/m4/time_rz.m4 b/m4/time_rz.m4
index 4378148978..af9fa02b57 100644
--- a/m4/time_rz.m4
+++ b/m4/time_rz.m4
@@ -13,6 +13,38 @@ AC_DEFUN
AC_REQUIRE([gl_HEADER_TIME_H_DEFAULTS])
AC_REQUIRE([AC_STRUCT_TIMEZONE])
+ # Mac OS X 10.6 loops forever with some time_t values less
+ # than -67768038400665599. See Bug#27706, Bug#27736, and
+ # https://lists.gnu.org/r/bug-gnulib/2017-07/msg00142.html
+ AC_CACHE_CHECK([whether localtime loops forever near extrema],
+ [gl_cv_func_localtime_infloop_bug],
+ [gl_cv_func_localtime_infloop_bug=no
+ AC_RUN_IFELSE(
+ [AC_LANG_PROGRAM(
+ [[#include <stdlib.h>
+ #include <string.h>
+ #include <unistd.h>
+ #include <time.h>
+ ]], [[
+ time_t t = -67768038400665600;
+ struct tm *tm;
+ char *tz = getenv ("TZ");
+ if (! (tz && strcmp (tz, "QQQ0") == 0))
+ return 0;
+ alarm (2);
+ tm = localtime (&t);
+ /* Use TM and *TM to suppress over-optimization. */
+ return tm && tm->tm_isdst;
+ ]])],
+ [TZ=QQQ0 ./conftest$EXEEXT || gl_cv_func_localtime_infloop_bug=yes],
+ [],
+ [gl_cv_func_localtime_infloop_bug="guessing no"])])
+ if test "$gl_cv_func_localtime_infloop_bug" = yes; then
+ AC_DEFINE([HAVE_LOCALTIME_INFLOOP_BUG], 1,
+ [Define if localtime-like functions can loop forever on
+ extreme arguments.])
+ fi
+
AC_CHECK_TYPES([timezone_t], [], [], [[#include <time.h>]])
if test "$ac_cv_type_timezone_t" = yes; then
HAVE_TIMEZONE_T=1
--
2.14.3
[-- Attachment #3: 0002-Avoid-using-unportable-integer-in-org-clock.patch --]
[-- Type: text/x-patch, Size: 1504 bytes --]
From c8e8d16810ec09139c560c77572d3372a2edd8d2 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 27 Mar 2018 13:48:13 -0700
Subject: [PATCH 2/2] Avoid using unportable integer in org-clock
* lisp/org/org-clock.el (org-clock--oldest-date): Avoid use of an
integer outside portable Emacs range. Go back to using a simple
check, since decode-time should no longer infloop.
---
lisp/org/org-clock.el | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el
index 4c5fcc64b0..c124abd391 100644
--- a/lisp/org/org-clock.el
+++ b/lisp/org/org-clock.el
@@ -478,17 +478,7 @@ org-clock--oldest-date
(funcall dichotomy
most-negative-fixnum
0
- (lambda (m)
- ;; libc in macOS 10.6 hangs when decoding times
- ;; around year -2**31. Limit `high' not to go
- ;; any earlier than that.
- (unless (and (eq system-type 'darwin)
- (string-match-p
- "10\\.6\\.[[:digit:]]"
- (shell-command-to-string
- "sw_vers -productVersion"))
- (<= m -1034058203135))
- (ignore-errors (decode-time (list m 0)))))))
+ (lambda (m) (ignore-errors (decode-time (list m 0))))))
(low
(funcall dichotomy
most-negative-fixnum
--
2.14.3
^ permalink raw reply related [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2018-03-27 21:19 ` Paul Eggert
@ 2018-03-28 17:15 ` Glenn Morris
2018-03-28 19:02 ` Charles A. Roelli
2018-03-28 19:33 ` Paul Eggert
2018-03-28 18:54 ` Charles A. Roelli
1 sibling, 2 replies; 39+ messages in thread
From: Glenn Morris @ 2018-03-28 17:15 UTC (permalink / raw)
To: Paul Eggert
Cc: Charles A. Roelli, Keith David Bershatsky, 27736, Noam Postavsky
Paul Eggert wrote:
> I noticed this problem when preparing a patch to catch this sort of
> issue. To fix this particular instance of the problem, I attempted to
> migrate the localtime workaround into editfns.c (so that the fix is
> more-general, and is not limited to org-clock), by installing the
> attached patches into master. Please give them a try, since I don't
> have easy access to Mac OS X. I'm still a bit fuzzy on exactly which
> timestamps cause Mac OS X localtime to go belly-up (is it timezone
> dependent?), so quite possibly the magic numbers in these patches need
> to be adjusted a bit so that the code will work in any timezone from
> TZ=AAA-24:59:59 to TZ=ZZZ24:59:59; please let me know.
The relevant org-clock.el code had been deleted in Org two months ago,
a change which was synced to Emacs today.
(Another example of my pet peeve, code in two repos being inefficient
for developers.)
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2018-03-28 17:15 ` Glenn Morris
@ 2018-03-28 19:02 ` Charles A. Roelli
2018-03-28 19:33 ` Paul Eggert
1 sibling, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2018-03-28 19:02 UTC (permalink / raw)
To: Glenn Morris; +Cc: npostavs, esq, 27736, eggert
> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 28 Mar 2018 13:15:16 -0400
>
> Paul Eggert wrote:
>
> > I noticed this problem when preparing a patch to catch this sort of
> > issue. To fix this particular instance of the problem, I attempted to
> > migrate the localtime workaround into editfns.c (so that the fix is
> > more-general, and is not limited to org-clock), by installing the
> > attached patches into master. Please give them a try, since I don't
> > have easy access to Mac OS X. I'm still a bit fuzzy on exactly which
> > timestamps cause Mac OS X localtime to go belly-up (is it timezone
> > dependent?), so quite possibly the magic numbers in these patches need
> > to be adjusted a bit so that the code will work in any timezone from
> > TZ=AAA-24:59:59 to TZ=ZZZ24:59:59; please let me know.
>
> The relevant org-clock.el code had been deleted in Org two months ago,
> a change which was synced to Emacs today.
>
> (Another example of my pet peeve, code in two repos being inefficient
> for developers.)
Thanks for noticing this, and for handling the merge.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2018-03-28 17:15 ` Glenn Morris
2018-03-28 19:02 ` Charles A. Roelli
@ 2018-03-28 19:33 ` Paul Eggert
2018-03-28 22:08 ` Paul Eggert
1 sibling, 1 reply; 39+ messages in thread
From: Paul Eggert @ 2018-03-28 19:33 UTC (permalink / raw)
To: Glenn Morris
Cc: Charles A. Roelli, Keith David Bershatsky, 27736, Noam Postavsky
On 03/28/2018 10:15 AM, Glenn Morris wrote:
> The relevant org-clock.el code had been deleted in Org two months ago,
> a change which was synced to Emacs today.
Unfortunately the new org code contains the expression (encode-time 0 0
0 0 0 -50000), which won't work on Emacs platforms where time_t is 32
bits or is unsigned, since such platforms cannot represent a time_t
value corresponding to the year -50000.
> (Another example of my pet peeve, code in two repos being inefficient
> for developers.)
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2018-03-28 19:33 ` Paul Eggert
@ 2018-03-28 22:08 ` Paul Eggert
0 siblings, 0 replies; 39+ messages in thread
From: Paul Eggert @ 2018-03-28 22:08 UTC (permalink / raw)
To: Glenn Morris
Cc: Charles A. Roelli, Keith David Bershatsky, 27736, emacs-org list,
Noam Postavsky
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
On 03/28/2018 12:33 PM, Paul Eggert wrote:
> Unfortunately the new org code contains the expression (encode-time 0
> 0 0 0 0 -50000), which won't work on Emacs platforms where time_t is
> 32 bits or is unsigned, since such platforms cannot represent a time_t
> value corresponding to the year -50000.
I installed the attached patch into Emacs master to try to fix this.
I'll CC: this to emacs-orgmode in the hopes that this won't get lost in
the next merge to Emacs master.
[-- Attachment #2: 0001-Port-recent-org-clock-fix-to-POSIX-time_t.patch --]
[-- Type: text/x-patch, Size: 1751 bytes --]
From 43994e484fadac28682542e75548e80cbb80987d Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 28 Mar 2018 15:03:40 -0700
Subject: [PATCH] Port recent org-clock fix to POSIX time_t
* lisp/org/org-clock.el (org-clock-special-range):
Don't assume support for time_t values less than 0, or less than
-2**31 for that matter (Bug#27736).
---
lisp/org/org-clock.el | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/lisp/org/org-clock.el b/lisp/org/org-clock.el
index ff32e28d1e..9be0d5bc1f 100644
--- a/lisp/org/org-clock.el
+++ b/lisp/org/org-clock.el
@@ -2239,8 +2239,18 @@ org-clock-special-range
(let* ((start (pcase key
(`interactive (org-read-date nil t nil "Range start? "))
;; In theory, all clocks started after the dawn of
- ;; humanity.
- (`untilnow (encode-time 0 0 0 0 0 -50000))
+ ;; humanity. However, the platform's clock
+ ;; support might not go back that far. Choose the
+ ;; POSIX timestamp -2**41 (approximately 68,000
+ ;; BCE) if that works, otherwise -2**31 (1901) if
+ ;; that works, otherwise 0 (1970). Going back
+ ;; billions of years would loop forever on Mac OS
+ ;; X 10.6 with Emacs 26 and earlier (Bug#27736).
+ (`untilnow
+ (let ((old 0))
+ (dolist (older '((-32768 0) (-33554432 0)) old)
+ (when (ignore-errors (decode-time older))
+ (setq old older)))))
(_ (encode-time 0 m h d month y))))
(end (pcase key
(`interactive (org-read-date nil t nil "Range end? "))
--
2.14.3
^ permalink raw reply related [flat|nested] 39+ messages in thread
* bug#27736: OSX 10.6.8: Building from master branch fails.
2018-03-27 21:19 ` Paul Eggert
2018-03-28 17:15 ` Glenn Morris
@ 2018-03-28 18:54 ` Charles A. Roelli
2018-03-28 21:29 ` Paul Eggert
[not found] ` <805d95e1-bfc0-bb40-ced7-c10bb5a7256e@cs.ucla.edu>
1 sibling, 2 replies; 39+ messages in thread
From: Charles A. Roelli @ 2018-03-28 18:54 UTC (permalink / raw)
To: Paul Eggert; +Cc: esq, 27736, npostavs
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 27 Mar 2018 14:19:22 -0700
>
> > > (<= m -1034058203136)
> > > (<= m -1034058203135))
> Unfortunately these numbers don't fit into a 30-bit integer and so they
> run afoul of a portability issue, namely, that files byte-compiled on a
> 64-bit Emacs should run on a 32-bit Emacs and vice versa. I noticed this
> problem when preparing a patch to catch this sort of issue. To fix this
> particular instance of the problem, I attempted to migrate the localtime
> workaround into editfns.c (so that the fix is more-general, and is not
> limited to org-clock), by installing the attached patches into master.
> Please give them a try, since I don't have easy access to Mac OS X. I'm
> still a bit fuzzy on exactly which timestamps cause Mac OS X localtime
> to go belly-up (is it timezone dependent?), so quite possibly the magic
> numbers in these patches need to be adjusted a bit so that the code will
> work in any timezone from TZ=AAA-24:59:59 to TZ=ZZZ24:59:59; please let
> me know.
Thank you for looking into this. At the moment, on an affected
system, ./configure has the following output:
checking whether localtime loops forever near extrema... no
and config.log shows:
configure:30520: checking whether localtime loops forever near extrema
configure:30554: gcc -std=gnu99 -o conftest -O0 -g3 conftest.c >&5
configure:30554: $? = 0
configure:30554: ./conftest
configure:30554: $? = 0
configure:30562: result: no
Bizarrely, the problem doesn't seem to show itself exactly in the
range I had quoted last July on bug-gnulib, so I applied the following
small change, with which the hang was detected.
--- a/m4/time_rz.m4
+++ b/m4/time_rz.m4
@@ -26,7 +26,7 @@ AC_DEFUN
#include <unistd.h>
#include <time.h>
]], [[
- time_t t = -67768038400665600;
+ time_t t = -67768038400666600;
struct tm *tm;
char *tz = getenv ("TZ");
if (! (tz && strcmp (tz, "QQQ0") == 0))
And then I got the following in the output of ./configure:
checking whether localtime loops forever near extrema... ./configure: line 30561: 35760 Alarm clock TZ=QQQ0 ./conftest$EXEEXT
yes
(The rest of the compilation process worked fine, so this change is on
the right track.)
I will try to find the exact boundary of the hang again. And the hang
is timezone-dependent, so that complicates things too.
^ permalink raw reply [flat|nested] 39+ messages in thread* bug#27736: OSX 10.6.8: Building from master branch fails.
2018-03-28 18:54 ` Charles A. Roelli
@ 2018-03-28 21:29 ` Paul Eggert
[not found] ` <805d95e1-bfc0-bb40-ced7-c10bb5a7256e@cs.ucla.edu>
1 sibling, 0 replies; 39+ messages in thread
From: Paul Eggert @ 2018-03-28 21:29 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: 27736, esq, Gnulib bugs, npostavs
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On 03/28/2018 11:54 AM, Charles A. Roelli wrote:
>
> - time_t t = -67768038400665600;
> + time_t t = -67768038400666600;
Thanks, I did that in Gnulib and propagated the result into Emacs master
(see attached patch).
> And then I got the following in the output of ./configure:
>
> checking whether localtime loops forever near extrema... ./configure: line 30561: 35760 Alarm clock TZ=QQQ0 ./conftest$EXEEXT
Thanks for mentioning that; I attempted to suppress the "Alarm clock"
stuff in the attached patch too.
> I will try to find the exact boundary of the hang again. And the hang
> is timezone-dependent, so that complicates things too.
I think we should be OK here, as the test case uses UTC so that it is
reproducible. The use of UTC could explain why the abovementioned
numeric change was needed.
[-- Attachment #2: 0001-time_rz-fix-workaround-for-Mac-OS-X-10.6-infloop.patch --]
[-- Type: text/x-patch, Size: 2448 bytes --]
From ad52c652a64ebe3523437fb9bb714f99c1ffa9e6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 28 Mar 2018 12:45:45 -0700
Subject: [PATCH] time_rz: fix workaround for Mac OS X 10.6 infloop
Problems reported by Charles A. Roelli (Bug#27736#117).
* m4/time_rz.m4 (gl_TIME_RZ): Use a slightly different timestamp.
Also, discard output, which clutters the 'configure' log.
---
ChangeLog | 7 +++++++
m4/time_rz.m4 | 9 +++++----
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 74f3bfc71..bd8df9a1e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2018-03-28 Paul Eggert <eggert@cs.ucla.edu>
+
+ time_rz: fix workaround for Mac OS X 10.6 infloop
+ Problems reported by Charles A. Roelli (Bug#27736#117).
+ * m4/time_rz.m4 (gl_TIME_RZ): Use a slightly different timestamp.
+ Also, discard output, which clutters the 'configure' log.
+
2018-03-27 Paul Eggert <eggert@cs.ucla.edu>
havelib: port to Solaris 10 /bin/sh
diff --git a/m4/time_rz.m4 b/m4/time_rz.m4
index af9fa02b5..555570625 100644
--- a/m4/time_rz.m4
+++ b/m4/time_rz.m4
@@ -13,8 +13,8 @@ AC_DEFUN([gl_TIME_RZ],
AC_REQUIRE([gl_HEADER_TIME_H_DEFAULTS])
AC_REQUIRE([AC_STRUCT_TIMEZONE])
- # Mac OS X 10.6 loops forever with some time_t values less
- # than -67768038400665599. See Bug#27706, Bug#27736, and
+ # Mac OS X 10.6 loops forever with some time_t values.
+ # See Bug#27706, Bug#27736, and
# https://lists.gnu.org/r/bug-gnulib/2017-07/msg00142.html
AC_CACHE_CHECK([whether localtime loops forever near extrema],
[gl_cv_func_localtime_infloop_bug],
@@ -26,7 +26,7 @@ AC_DEFUN([gl_TIME_RZ],
#include <unistd.h>
#include <time.h>
]], [[
- time_t t = -67768038400665600;
+ time_t t = -67768038400666600;
struct tm *tm;
char *tz = getenv ("TZ");
if (! (tz && strcmp (tz, "QQQ0") == 0))
@@ -36,7 +36,8 @@ AC_DEFUN([gl_TIME_RZ],
/* Use TM and *TM to suppress over-optimization. */
return tm && tm->tm_isdst;
]])],
- [TZ=QQQ0 ./conftest$EXEEXT || gl_cv_func_localtime_infloop_bug=yes],
+ [(TZ=QQQ0 ./conftest$EXEEXT) >/dev/null 2>&1 ||
+ gl_cv_func_localtime_infloop_bug=yes],
[],
[gl_cv_func_localtime_infloop_bug="guessing no"])])
if test "$gl_cv_func_localtime_infloop_bug" = yes; then
--
2.14.3
^ permalink raw reply related [flat|nested] 39+ messages in thread[parent not found: <805d95e1-bfc0-bb40-ced7-c10bb5a7256e@cs.ucla.edu>]
* bug#27736: OSX 10.6.8: Building from master branch fails.
[not found] ` <805d95e1-bfc0-bb40-ced7-c10bb5a7256e@cs.ucla.edu>
@ 2018-03-31 15:02 ` Charles A. Roelli
[not found] ` <m21sg02sr4.fsf@aurox.ch>
1 sibling, 0 replies; 39+ messages in thread
From: Charles A. Roelli @ 2018-03-31 15:02 UTC (permalink / raw)
To: Paul Eggert; +Cc: bug-gnulib, esq, 27736, npostavs
> From: Paul Eggert <eggert@cs.ucla.edu>
> Organization: UCLA Computer Science Department
> Date: Wed, 28 Mar 2018 14:29:38 -0700
>
> On 03/28/2018 11:54 AM, Charles A. Roelli wrote:
> >
> > - time_t t = -67768038400665600;
> > + time_t t = -67768038400666600;
>
> Thanks, I did that in Gnulib and propagated the result into Emacs master
> (see attached patch).
>
> > And then I got the following in the output of ./configure:
> >
> > checking whether localtime loops forever near extrema... ./configure: line 30561: 35760 Alarm clock TZ=QQQ0 ./conftest$EXEEXT
>
> Thanks for mentioning that; I attempted to suppress the "Alarm clock"
> stuff in the attached patch too.
Thank you. Strangely, it looks like it still prints the invocation,
however:
checking whether localtime loops forever near extrema... ./configure: line 30562: 55052 Alarm clock ( TZ=QQQ0 ./conftest$EXEEXT ) > /dev/null 2>&1
yes
Not sure why that is still so.
> > I will try to find the exact boundary of the hang again. And the hang
> > is timezone-dependent, so that complicates things too.
>
> I think we should be OK here, as the test case uses UTC so that it is
> reproducible. The use of UTC could explain why the abovementioned
> numeric change was needed.
Thanks, it should be okay to leave it at that. (I hadn't realized the
test case was using UTC.)
^ permalink raw reply [flat|nested] 39+ messages in thread[parent not found: <m21sg02sr4.fsf@aurox.ch>]
* bug#27736: OSX 10.6.8: Building from master branch fails.
[not found] ` <m21sg02sr4.fsf@aurox.ch>
@ 2018-04-01 20:32 ` Paul Eggert
0 siblings, 0 replies; 39+ messages in thread
From: Paul Eggert @ 2018-04-01 20:32 UTC (permalink / raw)
To: Charles A. Roelli; +Cc: bug-gnulib, esq, 27736, npostavs
Charles A. Roelli wrote:
> it looks like it still prints the invocation,
> however:
>
> checking whether localtime loops forever near extrema... ./configure: line 30562: 55052 Alarm clock ( TZ=QQQ0 ./conftest$EXEEXT ) > /dev/null 2>&1
> yes
>
> Not sure why that is still so
Since this is only a cosmetic issue (and only while running ./configure on an
Apple OS that is no longer supported by Apple) it's probably not worth pursuing
a fix. Thanks for checking, though.
^ permalink raw reply [flat|nested] 39+ messages in thread