2008-03-12 17:44:23     trunk & python

Document created by Aaronwu Employee on Aug 5, 2013
Version 1Show Document
  • View in full screen mode

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

Attachments

Outcomes