Hello,
I tried to install the mailman port (FreeBSD 8.0-RELEASE-p2 amd64) this morning and it bombs out during the install phase:
<snip> Compiling /usr/local/mailman/Mailman/TopicMgr.py ... Compiling /usr/local/mailman/Mailman/UserDesc.py ... Compiling /usr/local/mailman/Mailman/Utils.py ... Compiling /usr/local/mailman/Mailman/Version.py ... Compiling /usr/local/mailman/Mailman/__init__.py ... Compiling /usr/local/mailman/Mailman/htmlformat.py ... Compiling /usr/local/mailman/Mailman/i18n.py ... Compiling /usr/local/mailman/Mailman/versions.py ... *** Signal 11
Stop in /usr/ports/mail/mailman/work/mailman-2.1.12. *** Error code 1
Stop in /usr/ports/mail/mailman. *** Error code 1
Stop in /usr/ports/mail/mailman.
</snip>
the only corresponding thing I see in the logs is: Apr 22 11:18:51 greed kernel: pid 38872 (python2.6), uid 0: exited on signal 11 (core dumped)
Any thoughts on what to look at to correct this?
Thank you, Peter
Peter Clark wrote:
This is a FreeBSD packaging question, not a Mailman question. Signal 11 usually is a segmentation fault. Python shouldn't be seg faulting when trying to compile anything. I would guess it is a problem with the Python installation somehow or some kind of packaging incompatibility.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, 2010-04-22 at 11:32 -0500, Peter Clark wrote:
Isn't Signal 11 generally an indication of a hardware (e.g. memory) failure?
--
Lindsay Haisley | "Never expect the people who caused a problem
FMP Computer Services | to solve it." - Albert Einstein
512-259-1190 |
http://www.fmp.com |
Lindsay Haisley writes:
Isn't Signal 11 generally an indication of a hardware (e.g. memory) failure?
No. This is what Windows calls a "general protection fault", and it means that you've attempted to access memory that the operating system thinks you shouldn't. Possibly the most common low-level cause is dereferencing a NULL pointer, but overruns of dynamically allocated buffers and randomized pointers are also frequently observed.
High-level causes include program bugs, requesting that the compiler do inappropriate optimizations, buggy compilers, and linking to buggy libraries.
Either way, it's not a Mailman bug. Python (like many other high-level languages) promises to be safe, and not be crashable. It does quite well at that (I don't think I've ever observed a released Python to crash because of a bug in code written by the Python developers for Python), but it can't make promises for aggressively optimized distributions, for libraries, or for compilers.
Peter Clark wrote:
This is a FreeBSD packaging question, not a Mailman question. Signal 11 usually is a segmentation fault. Python shouldn't be seg faulting when trying to compile anything. I would guess it is a problem with the Python installation somehow or some kind of packaging incompatibility.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, 2010-04-22 at 11:32 -0500, Peter Clark wrote:
Isn't Signal 11 generally an indication of a hardware (e.g. memory) failure?
--
Lindsay Haisley | "Never expect the people who caused a problem
FMP Computer Services | to solve it." - Albert Einstein
512-259-1190 |
http://www.fmp.com |
Lindsay Haisley writes:
Isn't Signal 11 generally an indication of a hardware (e.g. memory) failure?
No. This is what Windows calls a "general protection fault", and it means that you've attempted to access memory that the operating system thinks you shouldn't. Possibly the most common low-level cause is dereferencing a NULL pointer, but overruns of dynamically allocated buffers and randomized pointers are also frequently observed.
High-level causes include program bugs, requesting that the compiler do inappropriate optimizations, buggy compilers, and linking to buggy libraries.
Either way, it's not a Mailman bug. Python (like many other high-level languages) promises to be safe, and not be crashable. It does quite well at that (I don't think I've ever observed a released Python to crash because of a bug in code written by the Python developers for Python), but it can't make promises for aggressively optimized distributions, for libraries, or for compilers.
participants (5)
-
Grant Taylor -
Lindsay Haisley -
Mark Sapiro -
Peter Clark -
Stephen J. Turnbull