Re: [ANNOUNCEMENT] Uploads for 12 August
Il 13/08/2013 11.52, Angelo Graziosi ha scritto: Yaakov wrote: The following packages (and their subpackages) have been updated for both arches: After this update my GTK builds of Emacs trunk do not work any more. For example, the bootstrap of rev. 113816 I did yesterday and that worked fine up to before this update, now fails so: $ emacs -Q [1] 3044 ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented [1]+ Aborted (core dumped) emacs -Q So, after this update, I tried a new bootstrap (rev.113838) but id fails in the same manner: if test no = yes; then \ rm -f bootstrap-emacs.exe; \ ln temacs.exe bootstrap-emacs.exe; \ else \ `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \ test X = X || -zex emacs.exe; \ mv -f emacs.exe bootstrap-emacs.exe; \ fi ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented /bin/sh: line 7: 896 Aborted (core dumped) `/bin/pwd`/temacs --batch --load loadup bootstrap Makefile:835: recipe for target `bootstrap-emacs.exe' failed make[2]: *** [bootstrap-emacs.exe] Error 1 make[2]: uscita dalla directory /work/emacs/Work/src Makefile:379: recipe for target `src' failed make[1]: *** [src] Error 2 make[1]: uscita dalla directory /work/emacs/Work Makefile:1040: recipe for target `bootstrap' failed make: *** [bootstrap] Error 2 build-emacs.sh: Bootstrap failure... Probably this issue affects also the Cygwin (GTK) package of Emacs.. It seems that the workaround is to start Emacs with G_SLICE=always-malloc, $ G_SLICE=always-malloc emacs -Q Ken, wasn't this issue fixed upstream some time ago? Just for the record, I can reproduce the same issue with emacs-x11 from Cygwin package. Ciao, Angelo. PS. My previous replay was sent to the wrong mailing list... :( Sorry! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 8:08 AM, Angelo Graziosi wrote: Il 13/08/2013 11.52, Angelo Graziosi ha scritto: Yaakov wrote: The following packages (and their subpackages) have been updated for both arches: After this update my GTK builds of Emacs trunk do not work any more. For example, the bootstrap of rev. 113816 I did yesterday and that worked fine up to before this update, now fails so: $ emacs -Q [1] 3044 ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented [1]+ Aborted (core dumped) emacs -Q So, after this update, I tried a new bootstrap (rev.113838) but id fails in the same manner: if test no = yes; then \ rm -f bootstrap-emacs.exe; \ ln temacs.exe bootstrap-emacs.exe; \ else \ `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \ test X = X || -zex emacs.exe; \ mv -f emacs.exe bootstrap-emacs.exe; \ fi ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented /bin/sh: line 7: 896 Aborted (core dumped) `/bin/pwd`/temacs --batch --load loadup bootstrap Makefile:835: recipe for target `bootstrap-emacs.exe' failed make[2]: *** [bootstrap-emacs.exe] Error 1 make[2]: uscita dalla directory /work/emacs/Work/src Makefile:379: recipe for target `src' failed make[1]: *** [src] Error 2 make[1]: uscita dalla directory /work/emacs/Work Makefile:1040: recipe for target `bootstrap' failed make: *** [bootstrap] Error 2 build-emacs.sh: Bootstrap failure... Probably this issue affects also the Cygwin (GTK) package of Emacs.. It seems that the workaround is to start Emacs with G_SLICE=always-malloc, $ G_SLICE=always-malloc emacs -Q Ken, wasn't this issue fixed upstream some time ago? Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) An alternative to patching Glib would be to fix the problem directly in Cygwin, but I don't know how hard that is and whether Corinna and cgf are interested. The issue, as I understand it, is this: Cygwin allows programs to supply their own malloc but not their own memalign. Glib calls memalign, which becomes Cygwin's memalign, which returns ENOSYS when Cygwin's malloc is not being used. There was a long discussion about this on the Cygwin mailing list in 2007. The thread starts at http://cygwin.com/ml/cygwin/2007-02/msg00469.html and continues at http://cygwin.com/ml/cygwin/2007-02/msg00503.html and did not resolve the issue. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 10:13 AM, Ken Brown wrote: On 8/13/2013 8:08 AM, Angelo Graziosi wrote: Il 13/08/2013 11.52, Angelo Graziosi ha scritto: Yaakov wrote: The following packages (and their subpackages) have been updated for both arches: After this update my GTK builds of Emacs trunk do not work any more. For example, the bootstrap of rev. 113816 I did yesterday and that worked fine up to before this update, now fails so: $ emacs -Q [1] 3044 ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented [1]+ Aborted (core dumped) emacs -Q So, after this update, I tried a new bootstrap (rev.113838) but id fails in the same manner: if test no = yes; then \ rm -f bootstrap-emacs.exe; \ ln temacs.exe bootstrap-emacs.exe; \ else \ `/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \ test X = X || -zex emacs.exe; \ mv -f emacs.exe bootstrap-emacs.exe; \ fi ***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented /bin/sh: line 7: 896 Aborted (core dumped) `/bin/pwd`/temacs --batch --load loadup bootstrap Makefile:835: recipe for target `bootstrap-emacs.exe' failed make[2]: *** [bootstrap-emacs.exe] Error 1 make[2]: uscita dalla directory /work/emacs/Work/src Makefile:379: recipe for target `src' failed make[1]: *** [src] Error 2 make[1]: uscita dalla directory /work/emacs/Work Makefile:1040: recipe for target `bootstrap' failed make: *** [bootstrap] Error 2 build-emacs.sh: Bootstrap failure... Probably this issue affects also the Cygwin (GTK) package of Emacs.. It seems that the workaround is to start Emacs with G_SLICE=always-malloc, $ G_SLICE=always-malloc emacs -Q Ken, wasn't this issue fixed upstream some time ago? Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) An alternative to patching Glib would be to fix the problem directly in Cygwin, but I don't know how hard that is and whether Corinna and cgf are interested. The issue, as I understand it, is this: Cygwin allows programs to supply their own malloc but not their own memalign. Glib calls memalign, which becomes Cygwin's memalign, which returns ENOSYS when Cygwin's malloc is not being used. There was a long discussion about this on the Cygwin mailing list in 2007. The thread starts at http://cygwin.com/ml/cygwin/2007-02/msg00469.html and continues at http://cygwin.com/ml/cygwin/2007-02/msg00503.html and did not resolve the issue. While we're waiting for a good solution, I could quickly repackage emacs-X11 so that it supplies a wrapper script that sets G_SLICE=always-malloc before calling emacs-X11. If people think that's a good idea, I should be able to do it later today. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Uploads for 12 August
Ken Brown wrote: Yes. The fix was to add the following for the Cygwin build, very early in main(): Indeed.. I have verified that G_SLICE_ALWAYS_MALLOC is 1 in config.h so that in emacs.c #ifdef G_SLICE_ALWAYS_MALLOC /* This is used by the Cygwin build. */ xputenv (G_SLICE=always-malloc); #endif defines rightly G_SLICE... setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. ...evidently, this is not sufficient, too late: Emacs has already aborted Probably, the problem is elsewhere... Ciao, Angelo. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Uploads for 12 August
On 2013-08-13 09:13, Ken Brown wrote: Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Exactly; in glib-2.36, g_type_init has been moved to a ctor, which is automatically called before main(); hence, this setenv is too late now. Mozilla software is also affected by this, see: https://bugzilla.gnome.org/show_bug.cgi?id=687763 https://bugzilla.mozilla.org/show_bug.cgi?id=833117 and many others. Firefox et al already use launcher scripts, so adding one more line won't be a big deal for them. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Yaakov -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Uploads for 12 August
On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Exactly; in glib-2.36, g_type_init has been moved to a ctor, which is automatically called before main(); hence, this setenv is too late now. Mozilla software is also affected by this, see: https://bugzilla.gnome.org/show_bug.cgi?id=687763 https://bugzilla.mozilla.org/show_bug.cgi?id=833117 and many others. Firefox et al already use launcher scripts, so adding one more line won't be a big deal for them. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_5JX_4OVdN.pgp Description: PGP signature
Re: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 2:09 PM, Yaakov (Cygwin/X) wrote: For now, I think you'll have to add a wrapper script. Which would cause issues (dos boxes, etc) when launching from a shortcut, unless you use run.exe or run2.exe. With run2 (assuming the upcoming(?) release fixes the known issues), you can set environment vars directly in the xml script: ?xml version=1.0 encoding=us-ascii? Run2Config xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=run2.xsd Global Environment Set var=G_SLICE value=always-malloc/ /Environment Target filename=/usr/bin/emacs.exe startin=~ Arg...various stuff.../Arg Arg...various stuff.../Arg Arg...various stuff.../Arg /Target /Global /Run2Config ...ought to work. But there are still extant issues with run2 IIRC (been on vacation for a while so my memory from pre-vacation is still fuzzy). -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 2:26 PM, Corinna Vinschen wrote: On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yes. The fix was to add the following for the Cygwin build, very early in main(): setenv (G_SLICE, always-malloc, 1); I don't know why this no longer works. Maybe Glib now does its memory management initialization before emacs's main() is entered. Exactly; in glib-2.36, g_type_init has been moved to a ctor, which is automatically called before main(); hence, this setenv is too late now. Mozilla software is also affected by this, see: https://bugzilla.gnome.org/show_bug.cgi?id=687763 https://bugzilla.mozilla.org/show_bug.cgi?id=833117 and many others. Firefox et al already use launcher scripts, so adding one more line won't be a big deal for them. Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
