New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_array fails on FreeBSD7 amd64 #48112
Comments
or in FreeBSD? 2.6rc1 and 3.0b3 both fail test_array on FreeBSD7 amd64 test_array passes in 2.5.2 on the same machine but fails test_list the *** Signal 9 |
2.6rc1 test_array passes on FreeBSD 6.3 i386. I don't have a 7.0 box Can you run the test on its own in verbose mode to get a bit more of an user@box$ ./python -E -tt Lib/test/regrtest.py -v test_array from the build directory. |
2.6rc2 and Python-3.0b3 test_array detail test_alloc_overflow (test.test_array.DoubleTest) ... Killed Fills swap space and dumps core. 2.5.2 test_list The FreeBSD ports patches fix this in 2.5.2. Specifically patching |
I've temporarily got a 7.0 amd64 system running and can confirm what you On a hunch, I used ulimit -v is used to set a process virtual memory I'm as yet none the wiser as to what to do with this info... |
On FreeBSD 7.0 i386, test_array passes without ulimit -v needing to be |
Does the attached patch help fix this at all? I encountered possibly the |
Mark, your patch will probably get the test to pass, but the underlying FreeBSD 7.0 introduced a new malloc() implementation that relies on I have posted a query about the new malloc()'s behaviour to a FreeBSD |
Thanks, Alan. I realised my answer was a shallow one after reading (too However, I have a suspicion that that particular array test /* Check for overflow */
if (nbytes / descr->itemsize != (size_t)size) {
return PyErr_NoMemory();
} and that the test dated from an era when it was fairly safe to assume So the array test is wrong, and I think this patch should be applied |
s/Alan/Andrew/. Need more coffee. Apologies. |
The patch looks fine to me, except that the failure message is now out |
On FreeBSD 7.0 amd64, applying Mark's patch does get the test to pass. As noted on python-dev, the response I got from the author of the new Martin: I'm missing something regarding your comment about the failure |
The 2**16 in the error message is wrong. Maybe the error message should "Attempt to create array of size larger than maxsize failed to raise A bit verbose, but more accurate. There's another error in that patch, too. The line: b * maxsize//3 + 1 should be b * (maxsize//3 + 1) (I was mistakenly reading the '*' as '*=', as in the first test.) |
As he says. |
Yes, the bleeding obvious became so after some sleep. Committed to trunk as r66708 with the extra fix and a more abbreviated Will forward port as appropriate to py3k. |
Was the fix forward ported or is this an issue for 3.1/2? |
Closing this old pending issue due to lack of activity. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: