From: Armin R. <ar...@ul...> - 2002-03-17 19:20:18
|
Hello, ----- Original Message ----- > On FreeBSD 4.5, GCC 2.95.3 I got a > > python in free(): warning: page is already free > Bus error (core dumped) This might be related to the reporter problem of 'realloc()' moving memor= y when shrinking a block, although I am not sure, as you mention that it wo= rks when Psyco is compiled in debug mode. As there is no FreeBSD machine I ca= n get access to, I cannot do more than wild guesses. Perhaps you can first = try to see if the problem really comes from 'realloc()' by removing the 'realloc()' call at all in codemanager.c, in psyco_shrink_buffer(). This will make Psyco use an unreasonably high amount of memory, but would tell= us if the bug comes from there. Also, could someone else listening on the psyco-devel list please see if = the bug is reproductible (and gives the same backtraces)? A bient=F4t, Armin. |
From: <cod...@us...> - 2002-03-18 00:14:05
|
I updated the bug,=20 http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D530401&group_i= d=3D41036&atid=3D429622 removing the realloc() did make the symptoms of the bug disappear. This bug corrupts the stack so the backtrace isn't always the same. On Sun, 17 Mar 2002, Armin Rigo wrote: > Hello, >=20 > ----- Original Message ----- > > On FreeBSD 4.5, GCC 2.95.3 I got a > > > > python in free(): warning: page is already free > > Bus error (core dumped) >=20 > This might be related to the reporter problem of 'realloc()' moving memor= y > when shrinking a block, although I am not sure, as you mention that it wo= rks > when Psyco is compiled in debug mode. As there is no FreeBSD machine I ca= n > get access to, I cannot do more than wild guesses. Perhaps you can first = try > to see if the problem really comes from 'realloc()' by removing the > 'realloc()' call at all in codemanager.c, in psyco_shrink_buffer(). This > will make Psyco use an unreasonably high amount of memory, but would tell= us > if the bug comes from there. >=20 > Also, could someone else listening on the psyco-devel list please see if = the > bug is reproductible (and gives the same backtraces)? >=20 >=20 > A bient=F4t, >=20 > Armin. >=20 >=20 |
From: Armin R. <ar...@ul...> - 2002-03-18 08:40:59
|
Hello, > removing the realloc() did make the symptoms of the bug disappear. I discovered some code I added in a recent CVS checkin that was buggy, in a way not unrelated to your bug report, so this might not be FreeBSD's fault after all. I will checkin the fix (together with the traceback support I'm working on). Armin |
From: <cod...@us...> - 2002-03-19 03:48:32
|
I just reran my tests after updating to the newest source. All problems disappear if I comment out the realloc() line in codemanager.c Otherwise they still persist, but it takes longer to crash with the new code modifications. compile with PSYCO_DEBUG=1 makes it pretty stable. I always compile with the following command string %python setup.py build -f --debug codepage ============================================================ On FreeBSD with PSYCO_DEBUG defined. Classic Regression Tests with Psyco successfully completed. All tests that succeeded twice in the same Python process also succeeded 4 more times with Psyco activated. Psyco compilation flags: ALL_CHECKS=1 DEFAULT_RECURSION=10 |
From: Armin R. <ar...@ul...> - 2002-03-19 17:34:09
|
Hello, ----- Original Message ----- > All problems disappear if I comment out the realloc() line in codemanager.c Ok... I don't know exactly why it is more stable with PSYCO_DEBUG=3D1. I = am not sure either that the assert() statement after the realloc() is not thrown away; it was intended to be present even in non-debugging compilations. I will replace it with a check and Py_FatalError() in the C= VS. If it triggers the error "psyco: realloc() moved code memory" then I'm afraid FreeBSD is not supported until the planned reorganization of Psyco into one core and possibly several code-producing back-ends. A bient=F4t, Armin |
From: <cod...@us...> - 2002-03-20 02:23:39
|
Greetings, if I run PSYCO_DEBUG=3D1 pretty stable, if the realloc line is= =20 commented out then never a problem. I haven't see the error you describe below. Ever.=20 I have only made a couple glances at the psyco code but could the stack=20 alignment or stack frame layout differences be causing the problem?=20 Is the realloc that accures during the=20 def f(): =09for x in range(100): =09=09pass f() f() I am assuming that python is creating a temporary array that needs to be fr= ee'd=20 later, is it realloc()'ing it to zero? Is it free'ing it then reallocing it? Would the best way to debug this be to compile psyco in statically to pytho= n and=20 step through the code with gdb? codepage > ----- Original Message ----- > > All problems disappear if I comment out the realloc() line in > codemanager.c >=20 > Ok... I don't know exactly why it is more stable with PSYCO_DEBUG=3D1. I = am > not sure either that the assert() statement after the realloc() is not > thrown away; it was intended to be present even in non-debugging > compilations. I will replace it with a check and Py_FatalError() in the C= VS. >=20 > If it triggers the error "psyco: realloc() moved code memory" then I'm > afraid FreeBSD is not supported until the planned reorganization of Psyco > into one core and possibly several code-producing back-ends. >=20 >=20 > A bient=F4t, >=20 > Armin >=20 >=20 |