2008-03-12 17:44:23 trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52411 Hi!
I have a strange problem with my python program. It crashes with NULL pointer access with new kernel. (some pyobject is at 0x17 address). The program is simple http server. I can't attach any output for now, maybe latter.
The same binary with the old one kernel 2.6.19 runs okay. Python compiled with an old toolchain fails on new kernel.
One note about my toolchain: it's built from trunk against old kernel.
So I guess:
1) something wrong with kernel
2) something changed in the kernel that uClibc built against old kernel isn't compatible with the trunk one.
ps: moreover I found that using another one allocator than slab leads kernel to unaligned memory access in my case after usb initialization.
vitja.
QuoteReplyEditDelete
2008-03-12 20:29:28 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52415 python seems to work OK for me on trunk, but i have no idea what your "python program" is ... i'm just testing by running `python` and putting in a few commands
building latest svn toolchain trunk against older kernel really isnt supported ... so unless you can reproduce with either the 2008R1 release or the latest trunk sources ...
QuoteReplyEditDelete
2008-03-13 03:35:50 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52429 Hi!
Try to compile python with binascii support and the python -c 'import base64' few times.
I recompiled toolchain with newer kernel version the same bug.
My program is simple http server that uses _socket builtin and select, python is type safe language and I don't use any own C modules, so that's plain python code and should work.
Here is example output of importing socket module
(gdb) target remote stamp:4444
Remote debugging using stamp:4444
Breakpoint 1 at 0x3200144: file ../Modules/python.c, line 24.
0x03200044 in _stext ()
(gdb) c
Continuing.
Breakpoint 1, main (argc=3, argv=0x32c0f68) at ../Modules/python.c:24
24 }
(gdb) c
Continuing.
Program received signal SIGILL, Illegal instruction.
0x032af524 in mylock ()
(gdb) disassemble
Dump of assembler code for function mylock:
0x032af524 <mylock+0>: ILLEGAL
0x032af526 <mylock+2>: CC |= ...... Illegal register .......;
0x032af528 <mylock+4>: R4 += 0x1d; /* ( 29) */
0x032af52a <mylock+6>: CC |= AN;
0x032af52c <mylock+8>: || R6 = M0 || CC = AZ;
0x032af530 <mylock+12>: R6 = M0;
0x032af532 <mylock+14>: CC = AZ;
0x032af534 <mylock+16>: ILLEGAL
0x032af536 <mylock+18>: CC |= ...... Illegal register .......;
0x032af538 <mylock+20>: ILLEGAL
0x032af53a <mylock+22>: CC |= ...... Illegal register .......;
End of assembler dump.
(gdb) backtrace
#0 0x032af524 in mylock ()
#1 0x03270164 in __uClibc_fini ()
#2 0x0326fd50 in exit ()
#3 0x03270322 in __uClibc_main ()
#4 0x033e804e in ?? ()
(gdb)
root:/> gdbserver 10.100.4.174:4444 python -c 'import socket'
Process python created; pid = 213
Listening on port 4444
Remote debugging from host 10.100.4.174
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
[ 29.176000] Undefined instruction
[ 29.176000] - May be used to emulate instructions that are not defined for
[ 29.176000] a particular processor implementation.
[ 29.176000] Deferred Exception context
[ 29.176000] CURRENT PROCESS:
[ 29.176000] COMM=python PID=213
[ 29.176000] TEXT = 0x03200040-0x03274aa0 DATA = 0x03274aa4-0x032aa464
[ 29.176000] BSS = 0x032aa464-0x032af764 USER-STACK = 0x032c0f64
[ 29.176000]
[ 29.176000] return address: [0x032af524]; contents of:
[ 29.176000] 0x032af500: 0f78 032c 1000 0000 f524 032a 63c0 0321
[ 29.176000] 0x032af510: e7b4 0328 0000 0000 0000 0000 0002 0000
[ 29.176000] 0x032af520: 0000 0000 [f554] 032a 64ec 0321 cb00 0303
[ 29.176000] 0x032af530: 30b4 0300 f704 032a e7b4 0328 09fb 0000
[ 29.176000]
[ 29.176000] SEQUENCER STATUS: Not tainted
[ 29.176000] SEQSTAT: 00060021 IPEND: 0030 SYSCFG: 0006
[ 29.176000] HWERRCAUSE: 0x18
[ 29.176000] EXCAUSE : 0x21
[ 29.176000] RETE: <0x00000000> { _run_init_process + 0xfffff000 }
[ 29.176000] RETN: <0x0336a000> [ python + 0x0 ]
[ 29.176000] RETX: <0x032af524> [ python + 0xaf524 ]
[ 29.176000] RETS: <0x03270164> [ python + 0x70124 ]
[ 29.176000] PC : <0x032af524> [ python + 0xaf524 ]
[ 29.176000] DCPLB_FAULT_ADDR: <0x032af508> [ python + 0xaf508 ]
[ 29.176000] ICPLB_FAULT_ADDR: <0x032af524> [ python + 0xaf524 ]
[ 29.176000]
[ 29.176000] PROCESSOR STATE:
[ 29.176000] R0 : 00000000 R1 : 032aa464 R2 : 032aa410 R3 : 0003ffff
[ 29.176000] R4 : 0337fff8 R5 : 03200140 R6 : 00000000 R7 : ffffffff
[ 29.176000] P0 : 0301b000 P1 : 0328e27c P2 : 032af524 P3 : 03274a80
[ 29.176000] P4 : 032c0f68 P5 : 00000000 FP : 032c0ee4 SP : 03369f24
[ 29.176000] LB0: 0326ca75 LT0: 0326ca74 LC0: 00000000
[ 29.176000] LB1: 0320d40b LT1: 0320d3fc LC1: 00000000
[ 29.176000] B0 : 00000000 L0 : 00000000 M0 : 00000000 I0 : 03014f88
[ 29.176000] B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 03031560
[ 29.176000] B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000
[ 29.176000] B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
[ 29.176000] A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
[ 29.176000] USP : 032c0ed8 ASTAT: 02003005
[ 29.176000]
[ 29.176000] Hardware Trace:
[ 29.176000] 0 Target : <0x000045e4> { _trap_c + 0x0 }
[ 29.176000] Source : <0xffa006ec> { _exception_to_level5 + 0xb4 }
[ 29.176000] 1 Target : <0xffa00638> { _exception_to_level5 + 0x0 }
[ 29.176000] Source : <0xffa00594> { _ex_trap_c + 0x5c }
[ 29.176000] 2 Target : <0xffa00538> { _ex_trap_c + 0x0 }
[ 29.176000] Source : <0xffa0078c> { _trap + 0x28 }
[ 29.176000] 3 Target : <0xffa00764> { _trap + 0x0 }
[ 29.176000] Source : <0x03270162> [ python + 0x70122 ]
[ 29.176000] 4 Target : <0x0327014e> [ python + 0x7010e ]
[ 29.176000] Source : <0x0327013c> [ python + 0x700fc ]
[ 29.176000] 5 Target : <0x03270120> [ python + 0x700e0 ]
[ 29.176000] Source : <0x0326fd4c> [ python + 0x6fd0c ]
[ 29.176000] 6 Target : <0x0326fd4c> [ python + 0x6fd0c ]
[ 29.176000] Source : <0x032701a0> [ python + 0x70160 ]
[ 29.176000] 7 Target : <0x03270194> [ python + 0x70154 ]
[ 29.176000] Source : <0x0326fd48> [ python + 0x6fd08 ]
[ 29.176000] 8 Target : <0x0326fd44> [ python + 0x6fd04 ]
[ 29.176000] Source : <0x0326fd3e> [ python + 0x6fcfe ]
[ 29.176000] 9 Target : <0x0326fd32> [ python + 0x6fcf2 ]
[ 29.176000] Source : <0x03270190> [ python + 0x70150 ]
[ 29.176000] 10 Target : <0x03270184> [ python + 0x70144 ]
[ 29.176000] Source : <0x0326fd2e> [ python + 0x6fcee ]
[ 29.176000] 11 Target : <0x0326fd26> [ python + 0x6fce6 ]
[ 29.176000] Source : <0x032701a0> [ python + 0x70160 ]
[ 29.176000] 12 Target : <0x03270194> [ python + 0x70154 ]
[ 29.176000] Source : <0x0326fd22> [ python + 0x6fce2 ]
[ 29.176000] 13 Target : <0x0326fd04> [ python + 0x6fcc4 ]
[ 29.176000] Source : <0x0327031e> [ python + 0x702de ]
[ 29.176000] 14 Target : <0x0327031e> [ python + 0x702de ]
[ 29.176000] Source : <0x032002c6> [ python + 0x286 ]
[ 29.176000] 15 Target : <0x032002be> [ python + 0x27e ]
[ 29.176000] Source : <0x032006fe> [ python + 0x6be ]
[ 29.176000] Stack from 03369f04:
[ 29.176000] 0000003c ffa006f0 001c1228 001c1228 001c1224 033c7f20 0000004e 032705f4
[ 29.176000] 032af524 00000030 00060021 00000000 0336a000 032af524 032af524 03270164
[ 29.176000] 00000000 02003005 0320d40b 0326ca75 0320d3fc 0326ca74 00000000 00000000
[ 29.176000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 29.176000] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 29.176000] 00000000 00000000 03031560 03014f88 032c0ed8 032c0ee4 00000000 032c0f68
[ 29.176000]
[ 29.176000] Call Trace:
[ 29.176000] [<0003ffff>] _init_file+0x3b/0x4c
[ 29.176000]
and few output from strace:
read(6, "\0Helper to provide extensibility"..., 4803) = 4795
read(6, "", 8) = 0
close(6) = 0
stat64("types", 0x32b4094) = -1 ENOENT (No such file or directory)
open("types.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("types.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/python24.zip/types", 0x32b4094) = -1 ENOENT (No such file or directory)
open("/usr/lib/python24.zip/types.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT[(No such file or directory)
open("/usr/lib/python24.zip/types.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
stat64("/usr/lib/python2.4/types", 0x32b4094) = -1 ENOENT (No such file or directory)
open("/usr/lib/python2.4/types.py", O_RDONLY|O_LARGEFILE) = 6
ioctl(6, SNDCTL_TMR_TIMEBASE or TCGETS, 0x32b4020) = -1 ENOTTY (Inappropriate ioctl for device)
fstat64(6, {st_mode=S_IFREG|0644, st_size=2154, ...}) = 0
open("/usr/lib/python2.4/types.pyc", O_RDONLY|O_LARGEFILE) = 7
ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0x32b4100) = -1 ENOTTY (Inappropriate ioctl for device)
read(7, "m\362\r\nw\323\330Gc\0\0\0\0\0\0\0\0\5\0\0\0@\0\0\0sN\2"..., 256) = 256
fstat64(7, {st_mode=S_IFREG|0644, st_size=2555, ...}) = 0
read(7, "\0i$\0\203\1\0Z%\0Wn\23\0\4e&\0j\n\0o\7\0\1\1\1\1n\2\0"..., 2307) = 2299
read(7, "", 8) = 0
mmap2(NULL, 266240, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x400000
close(7) = 0
mmap2(NULL, 102400, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x33e0000
close(6) = 0
close(5) = 0
close(4) = 0
229.708000] Undefined instruction
[ 229.708000] - May be used to emulate instructions that are not defined for
[ 229.708000] a particular processor implementation.
[ 229.708000] Deferred Exception context
QuoteReplyEditDelete
2008-03-13 03:47:10 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52431 please post standalone python code that triggers the crash ... i cant really take what you've posted here and sanely reproduce things
QuoteReplyEditDelete
2008-03-13 03:59:04 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52432 okay
try this ones few times:
##1.py ~ -c 'import socket'
import socket
##2.py ~ -c 'import base64'
import base64
To run these you should to enable _socket and binascii python builtins in Modules/Setup.dist
QuoteReplyEditDelete
2008-03-13 09:17:46 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52450 Strange things says strace, why don't it print munmap calls?
simple test program and strace output:
#include <stdlib.h>
/*2.6.24
root:/> strace ./test
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x35d4000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x35ca000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x313b000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x35c8000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x34cc000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x586000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x5c8000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x3208000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x320a000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x5fa000
_exit(0) = ?
*/
/* 2.6.19
root:~> strace ./test
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x72e000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x730000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x783000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x732000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x734000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x736000
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS|0x4000000, 0, 0) = 0x738000
munmap(0x72e000, 8192) = 0
munmap(0x730000, 8192) = 0
munmap(0x732000, 8192) = 0
exit(0) = ?
*/
int main(int argc, char **argv)
{
char *strs[10];
int i;
for (i = 0; i < 10; i++) {
strs[i] = malloc(4096);
}
for (i = 0; i < 10; i++) {
free(strs[i]);
}
return 0;
}
QuoteReplyEditDelete
2008-03-13 13:17:44 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52465 i dont really see a problem with that ... uClibc has a memory layer in it, so not all malloc's/free's go to the kernel
QuoteReplyEditDelete
2008-03-13 13:41:08 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52467 That was day of pain. python didn't worked for me anyway I'll try 2008R1. Kernel panics, applications receiving signals, and after all i deleted my recent atmega sources)
So could you send me output of the following command python -c 'import base64' run it twice, pls.
By idea that should be no output. Maybe something wrong with my environment.
thanks,
vitja.
QuoteReplyEditDelete
2008-03-13 15:46:14 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52482 Back again.
I tried 2008R1 the same story as with the trunk.
2007R1 works but:
root:/> python -c 'import base64'
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
[42949392.390000] munmap of non-mmaped memory by process 133 (python): 03244000
root:/>
QuoteReplyEditDelete
2008-03-13 23:08:06 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52496 the mmap issue is most likely already fixed in 2008R1/trunk
try adding --without-threads to the python configure line
QuoteReplyEditDelete
2008-03-14 01:38:45 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52500 Here are my configure options,
--disable-ipv6 \
--without-threads \
--disable-shared \
--disable-unicode
Also I attach setup.dist file.
Both trunk and 2008R1 doesn't work for me, 2007R1 does.
Setup.dist
QuoteReplyEditDelete
2008-03-14 06:16:13 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52529 building up current trunk works for me doing just:
python -c 'import base64'
so i'll need a larger test case ...
QuoteReplyEditDelete
2008-03-14 06:30:55 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52533 Ok. Here it is. Run it as python myserver.py
It should create little server on 80 port, it uses login admin, password admin.
vitja.
py-httpd.tar.bz2
QuoteReplyEditDelete
2008-03-14 15:45:31 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52550 Mike, if that worked for you could you please send me your kernel configuration?
Thanks,
vitja.
QuoteReplyEditDelete
2008-03-18 02:42:05 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52629 Mike, did you tried the program?
QuoteReplyEditDelete
2008-03-18 10:03:03 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52699 it did work for me ... i logged in and then held down F5 to force a lot of refreshes ... the console showed css/png files being served up over and over
i'm using latest svn trunk with default BF537-STAMP config with these changes:
- set to FDPIC rather than FLAT
- enable python
- add --without-threads to CONF_OPTS in user/python/Makefile
QuoteReplyEditDelete
2008-03-19 02:52:36 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52732 Thanks Mike!
The only difference I see is binary format. I still use flat.
So I can guess that the problem is somewhere about binfmt_flat.
QuoteReplyEditDelete
2008-03-19 03:21:37 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52736 not really ... the default stack for FDPIC binaries are much much larger than that of FLAT binaries ... you should use flthdr and try increasing the stack size of python
unfortunately, there isnt a "good" stack size for python as it's an interpreted language and the required stack size is highly dependent on what you're doing in your python ...
QuoteReplyEditDelete
2008-03-19 04:14:30 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52739 I tried to increase stack size, that doesn't help.
I think this issue is kernel related, as the same binaries in the same userland works different.
That's okay with 2.6.19 but doesn't work with trunk.
> unfortunately, there isnt a "good" stack size for python as it's an interpreted language and the required stack size is highly dependent on what you're doing in your python ...
I'm not sure here.
QuoteReplyEditDelete
2008-03-19 15:14:41 Re: trunk & python
Vitja Makarov (RUSSIAN FEDERATION)
Message: 52767 Thanks Mike!
I already tried to increase stack size, but that wasn't enough. Setting it to 128K solves the issue.
I tried 8K,16K,32K. I'm wondering how does it works with 2.6.19 kernel.
So I think it's reasonable to add something like this to python Makefile:
ifeq ($(CONFIG_FMT_USE_FLAT, y)
LDFLAGS += -Wl,-elf2flt="-s 131072"
endif
QuoteReplyEditDelete
2008-03-19 16:48:58 Re: trunk & python
Mike Frysinger (UNITED STATES)
Message: 52773 just set FLTFLAGS env var like other build files ... see strace/Makefile for instance
QuoteReplyEditDelete
2010-04-12 10:46:54 Re: trunk & python & BF561
Edwin Bland (UNITED STATES)
Message: 88335
Hi all:
Thanks for the above thread. I had been having an issue with BF561/python interpreter crashing frequently ... even before I added my python extension module. After re-configuring python: --without-threads & increasing the stacksize(FLTFLAGS -s 131072) it seems to be hugely improved... Previously about 1-2 in 10 times on entering the python interpreter... would cause a kernel crash.... after the above change it seems to be upwards of 40-50x & then I occasionally get a python NULL pointer report ... then a kernel crash... That's with my extension module included... I'll pull the extension module out to see if that's the culprit or if it's just the act of entering/exiting the interpreter alone... I had read that python doesn't free it's memory well on a nommu based system.... At this point I'm inclined to believe my extension module is the source of the problem... now that I've made the above changes.... but I'll verify this...
I'm trying to determine if we can use the python environment on blackfin as a 'master control' -vs- having a system supervisor process which then launches python scripts... At this point I'm just trying to understand the blackfin/python environment a bit better. If someone knows if python releases its memory resources upon exiting from the interpreter I'd love to see a post. As best as I can glean from other postings elsewhere... python by design doesn't release it's resources as long as you remain in the interpreter... in an embedded space I'm trying to understand how to work with this.... it seems that exiting from the interpreter may take care of this without the boundaries of our usage... if we ignore the fragmentation problem for now... or understand the # of times we can exit/re-enter the interpreter....
Regards,
Edwin Bland,
Mansfield, TX
QuoteReplyEditDelete
2010-04-12 14:10:41 Re: python & BF561 -- stable?
Edwin Bland (UNITED STATES)
Message: 88340
Hi all:
I've removed our python extension module from the build & have a failure that seems fairly consistent with the below theme:
(I'm ignoring the import site failure... perhaps this is one of many problems).
'import site' failed; use -v for traceback
Data access misaligned address violation
- Attempted misaligned data memory or data cache access.
Deferred Exception context
CURRENT PROCESS: ...
I have a python script which follows & a shell script... both are trivial.
I execute the shell script on the target which then executes the python script.... one after another... & prints out the iteration # we're on... The system crashes inconsistently... some times after 3x some times after 14x... one time it went 151x...
very strange... this is with the python stack set to 131072... & thread support removed.
Context:
DEMOnolib.py:
import sys
print "exiting python"
sys.exit()
DEMOnolib.sh
!/bin/sh
CNTVAR=0
echo $CNTVAR
python DEMOnolib.py
CNTVAR=`expr $CNTVAR + 1`
echo $CNTVAR
...
Any suggestions are welcome... I believe this is likely blackfin specific....... but it could also be uClinux specific only.... not sure... I'm hoping I'm doing something incorrect... At this point I'm not seeing what it might be. I've also built python with gdb & stepped through it on the target (albeit for other scripts... not the above described) & it seems to be failing in the memory de-allocation section....
Any suggestions?
Regards,
Edwin Bland,
QuoteReplyEditDelete
2010-04-12 14:47:22 Re: python & BF561 -- stable--: yes: with PYTHONPATH & PYTHONHOME set
Edwin Bland (UNITED STATES)
Message: 88341
Hi all:
I believe I can explain the source of the above described python crash... two key python environment variables weren't set on my target:
PYTHONPATH & PYTHONHOME... after setting these to their appropriate locations I have something which is useable. This would be nice to have these variables set as part of the distribution .... but I can work with it... I would guess there's a good reason they're not set to default values... The above described scripts successfully completed several hundred times before I stopped them....
my values were: PYTHONPATH=/usr/bin & PYTHONHOME=/usr/lib/python2.4
The feedback wasn't obvious...however... kernel crashing... if it wasn't able to find something... I could guess that a null pointer might be returned somewhere in python's bowels/inner workings... all 299 files of it... I'll go back, put my extension module back in & repeat my baseline test scripts...
Please close this.
Regards,
Edwin Bland