Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

Thank to Rene, Claudio and Brian,

On Wednesday 16 September 2009, Brian Fisher wrote:
> Well that looks like a very complicated way to clear the screen, which also
> involves blitting a surface to itself (you are blitting the
> pygame.display.get_surface() to the pygame.display.get_surface() after
> clearing the surface)
>

Claudio said much the same thing.  I must admit it looked over complicated 
when I put it in the email.  This is my roughly my second attempt at something 
non-trivial with python so I am very much a learner.  

> The symptoms of your original bug report seem remarkably similar to a bug
> that existed in SDL with blitting a surface to itself due to a change in
> gcc 4.0 (it stopped restoring the direction flag). The exact problem in
> that case was that the SDL code to blit a surface to itself was special
> cased, and that special case assumed the direction flag was cleared when it
> did a rep movsb. But since it wasn't with the new gcc, if the direction
> flag had been set elsewhere, then the copy went in the other way and either
> corrupted memory, resulting in that string state error message, or crashed

Slack 13.0 64 bit:  gcc 4.3.3   sdl  1.2.13
Slack 13.0 32 bit:  gcc 4.3.3   sdl  1.2.13
Slack 12.0 (32 bit only)gcc 4.2.4   sdl  1.2.13

>
> I don't recall how that old bug was (or was not) resolved for pygame, but
> there is history on that bug on the list archive.
>
> Lenard probably remembers it much better than me.
>
> ... but you could also fix this by replacing thatvery  convoluted
> clearScreen body with a simple self.screen.fill((0,0,0))

Yes, works, I also ought to put that function somewhere more sensible as 
well...

Thanks All,

Pete
-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[René Dudfield]

yes, I think you are right Brian.  Also your workaround should fix it.

That bug has been fixed in many versions of SDL... but obviously not
the one slackware has on 32bit.  It's been put into the SDL bug
tracker and is planned to be fixed for the SDL 1.2.14 release.  Until
then, will just have to avoid doing self screen blits.

cu,

On Wed, Sep 16, 2009 at 9:31 PM, Brian Fisher  wrote:
> Well that looks like a very complicated way to clear the screen, which also
> involves blitting a surface to itself (you are blitting the
> pygame.display.get_surface() to the pygame.display.get_surface() after
> clearing the surface)
>
> The symptoms of your original bug report seem remarkably similar to a bug
> that existed in SDL with blitting a surface to itself due to a change in gcc
> 4.0 (it stopped restoring the direction flag). The exact problem in that
> case was that the SDL code to blit a surface to itself was special cased,
> and that special case assumed the direction flag was cleared when it did a
> rep movsb. But since it wasn't with the new gcc, if the direction flag had
> been set elsewhere, then the copy went in the other way and either corrupted
> memory, resulting in that string state error message, or crashed
>
> I don't recall how that old bug was (or was not) resolved for pygame, but
> there is history on that bug on the list archive.
>
> Lenard probably remembers it much better than me.
>
> ... but you could also fix this by replacing thatvery  convoluted
> clearScreen body with a simple self.screen.fill((0,0,0))
>
>
> On Wed, Sep 16, 2009 at 11:15 AM, Peter Chant  wrote:
>>
>> D'oh so obvious.  What I regularly do whilst developing things, but not
>> when
>> bugs suddenly appear.
>>
>> FOUND IT!
>>     self.screen.blit(clear,(0,0))
>>
>>
>>  - look for the exclamation marks
>>
>>    def clearScreen(self):
>>        print "In clearScreen"
>>        print "About to call pygame.display_get_surface()"
>>        clear = pygame.display.get_surface()
>>        print "About to fill surface to clear it"
>>        clear.fill((0,0,0))
>>        print "About to self.screen.blit -  this crashes"
>>        self.screen.blit(clear,(0,0))
>>        print "just blitted - ! does not get to here"
>>
>>
>> self.screen is initialised by the output of another class.
>>  self.screen = h.screen
>>
>> in class h
>>
>>  self.screen=pygame.display.get_surface()
>>
>
>

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[claudio canepa]

On Wed, Sep 16, 2009 at 3:15 PM, Peter Chant  wrote:

> On Wednesday 16 September 2009, René Dudfield wrote:
> > I guess the next step is to try and put print debugging in.
> >
> > You start by putting a few print statements in, and see where it gets
> > up to.  Then you refine until you get really close to it... doing a
> > binary search of your source until you find the place/places that make
> > it crash.
> >
>
> D'oh so obvious.  What I regularly do whilst developing things, but not
> when
> bugs suddenly appear.
>
> FOUND IT!
> self.screen.blit(clear,(0,0))
>
>
>  - look for the exclamation marks
>
>def clearScreen(self):
>print "In clearScreen"
>print "About to call pygame.display_get_surface()"
>clear = pygame.display.get_surface()
>print "About to fill surface to clear it"
>clear.fill((0,0,0))
>print "About to self.screen.blit -  this crashes"
>self.screen.blit(clear,(0,0))
>print "just blitted - ! does not get to here"
>
>
> self.screen is initialised by the output of another class.
>  self.screen = h.screen
>
> in class h
>
>  self.screen=pygame.display.get_surface()
>
>
> Only fails on 32 bit Slack 13.0.
>
>
>
> --
> Peter Chant
>  


so functionally

surf = pygame.dispay.get_surface()
surf.fill((0,0,0))
surf.blit(surf,(0,0))

fails.

>From your app point of view, the blit line is superfluous.

your code will be

def clearScreen(self):
self.screen.fill((0,0,0))

>From the pygame point of view, there is a possible bug, there is a bug: it
should work or it should raise some meaningful error.

--
claxo

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Brian Fisher]

Well that looks like a very complicated way to clear the screen, which also
involves blitting a surface to itself (you are blitting the
pygame.display.get_surface() to the pygame.display.get_surface() after
clearing the surface)

The symptoms of your original bug report seem remarkably similar to a bug
that existed in SDL with blitting a surface to itself due to a change in gcc
4.0 (it stopped restoring the direction flag). The exact problem in that
case was that the SDL code to blit a surface to itself was special cased,
and that special case assumed the direction flag was cleared when it did a
rep movsb. But since it wasn't with the new gcc, if the direction flag had
been set elsewhere, then the copy went in the other way and either corrupted
memory, resulting in that string state error message, or crashed

I don't recall how that old bug was (or was not) resolved for pygame, but
there is history on that bug on the list archive.

Lenard probably remembers it much better than me.

... but you could also fix this by replacing thatvery  convoluted
clearScreen body with a simple self.screen.fill((0,0,0))


On Wed, Sep 16, 2009 at 11:15 AM, Peter Chant  wrote:

> D'oh so obvious.  What I regularly do whilst developing things, but not
> when
> bugs suddenly appear.
>
> FOUND IT!
> self.screen.blit(clear,(0,0))
>
>
>  - look for the exclamation marks
>
>def clearScreen(self):
>print "In clearScreen"
>print "About to call pygame.display_get_surface()"
>clear = pygame.display.get_surface()
>print "About to fill surface to clear it"
>clear.fill((0,0,0))
>print "About to self.screen.blit -  this crashes"
>self.screen.blit(clear,(0,0))
>print "just blitted - ! does not get to here"
>
>
> self.screen is initialised by the output of another class.
>  self.screen = h.screen
>
> in class h
>
>  self.screen=pygame.display.get_surface()
>
>

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Wednesday 16 September 2009, René Dudfield wrote:
> I guess the next step is to try and put print debugging in.
>
> You start by putting a few print statements in, and see where it gets
> up to.  Then you refine until you get really close to it... doing a
> binary search of your source until you find the place/places that make
> it crash.
>

D'oh so obvious.  What I regularly do whilst developing things, but not when 
bugs suddenly appear.

FOUND IT!
 self.screen.blit(clear,(0,0))


 - look for the exclamation marks

def clearScreen(self):
print "In clearScreen"
print "About to call pygame.display_get_surface()"
clear = pygame.display.get_surface()
print "About to fill surface to clear it"
clear.fill((0,0,0))
print "About to self.screen.blit -  this crashes"
self.screen.blit(clear,(0,0))
print "just blitted - ! does not get to here"


self.screen is initialised by the output of another class.
  self.screen = h.screen

in class h 

  self.screen=pygame.display.get_surface()


Only fails on 32 bit Slack 13.0.



>
> cheers,
>
> On Tue, Sep 15, 2009 at 11:56 PM, Peter Chant  wrote:
> > On Friday 11 September 2009, René Dudfield wrote:
> >> ah.  that stack trace doesn't show where the problem is... looks like
> >> the stack is getting corrupted.
> >
> > Any thoughts on what next?  My next move, in the abscence of any better
> > plan is to try to downgrade the version of python used in slack 13.0 to
> > that used in slack 12.2 - as everything works in 12.2.  This does not
> > find the bug but it gets me up and running.
> >
> > Pete
> >
> >
> > --
> > Peter Chant
> > http://www.petezilla.co.uk


-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[René Dudfield]

I guess the next step is to try and put print debugging in.

You start by putting a few print statements in, and see where it gets
up to.  Then you refine until you get really close to it... doing a
binary search of your source until you find the place/places that make
it crash.


cheers,

On Tue, Sep 15, 2009 at 11:56 PM, Peter Chant  wrote:
> On Friday 11 September 2009, René Dudfield wrote:
>> ah.  that stack trace doesn't show where the problem is... looks like
>> the stack is getting corrupted.
>
> Any thoughts on what next?  My next move, in the abscence of any better plan
> is to try to downgrade the version of python used in slack 13.0 to that used
> in slack 12.2 - as everything works in 12.2.  This does not find the bug but 
> it
> gets me up and running.
>
> Pete
>
>
> --
> Peter Chant
> http://www.petezilla.co.uk
>

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Friday 11 September 2009, René Dudfield wrote:
> ah.  that stack trace doesn't show where the problem is... looks like
> the stack is getting corrupted.

Any thoughts on what next?  My next move, in the abscence of any better plan 
is to try to downgrade the version of python used in slack 13.0 to that used 
in slack 12.2 - as everything works in 12.2.  This does not find the bug but it 
gets me up and running.

Pete


-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Greg Ewing]

Peter Chant wrote:

Hmm.  I'm fairly new to python.  I was trying to work out if modules ran 
similarly to namespaces.


If you mean C++ namespaces, no, not really. If you give
your module the same name as a built-in one, your module
doesn't get merged with the built-in one -- it overrides
it, leading to much confusion.

--
Greg

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Saturday 12 September 2009, Jason M. Marshall wrote:
> > > having your own select module is a problem.
>
> Actually, duplicating standard module names is not a problem if you put
> your scripts within a package structure. Then, you may use a syntax like
> "from my_game_package import select" to import your module unambiguously.
>
> http://docs.python.org/tutorial/modules.html#packages

Thanks.  I think my problem that I have created there is that I have tried to 
make my app, a simple media player for my media pc, use a package structure 
using setuptools.  However, I have not understood packages and have imported 
files directly as if I weren't using such a structure - I think - as I learn 
I'll sort it out.  Thanks for the reference.

Pete


-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Jason M. Marshall]

> > having your own select module is a problem.

Actually, duplicating standard module names is not a problem if you put your 
scripts within a package structure. Then, you may use a syntax like "from 
my_game_package import select" to import your module unambiguously.

http://docs.python.org/tutorial/modules.html#packages

Jason


  

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Friday 11 September 2009, René Dudfield wrote:
> ah.  that stack trace doesn't show where the problem is... looks like
> the stack is getting corrupted.
>
> yeah, having your own select module is a problem.  Since the select
> module is a python one that other python modules use.  It's an
> annoying problem with the python module system :(

Hmm.  I'm fairly new to python.  I was trying to work out if modules ran 
similarly to namespaces.

>
> So can you try renaming your module, and see if that fixes the problem?

Yes, but guess what the answer is, no luck.  I renamed select.py pselect.py 
and housekeeping.py phousekeeping.py.

Pete

-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[René Dudfield]

ah.  that stack trace doesn't show where the problem is... looks like
the stack is getting corrupted.

yeah, having your own select module is a problem.  Since the select
module is a python one that other python modules use.  It's an
annoying problem with the python module system :(

So can you try renaming your module, and see if that fixes the problem?

cheers,

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Friday 11 September 2009, René Dudfield wrote:
> Hi,
>
> thanks for all that testing!
>

Thank you for developing and helping.  Also, selfishly, its all in my self 
interest to get this fixed!

> if you could type 'where' after your program crashes in gdb, that
> shows a stack trace(or attempts to show a stack trace).  That should
> show us where the problem is.
>

Hmm, I may be barking up the wrong tree with pygame...


Is this it:

 #11 0xb7f497ca in PyDict_GetItemString () from /usr/lib/libpython2.6.so.1.0 
???


bash-3.1# gdb python 
GNU gdb 6.8  
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.   
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"   
and "show warranty" for details. 
This GDB was configured as "i486-slackware-linux"... 
(no debugging symbols found) 
(gdb) run pslide.py  
Starting program: /usr/bin/python pslide.py  
(no debugging symbols found) 
(no debugging symbols found) 
(no debugging symbols found) 
(no debugging symbols found) 
[Thread debugging using libthread_db enabled]
(no debugging symbols found) 
(no debugging symbols found) 
(no debugging symbols found) 
(no debugging symbols found) 
[New Thread 0xb7d346c0 (LWP 3112)]   
(no debugging symbols found) 
(no debugging symbols found) 
housekeeping 
select   
__main__ 
[New Thread 0xb73deb90 (LWP 3115)]   
[New Thread 0xb6ba0b90 (LWP 3116)]
Output:  . ['pslide-old2.pyc', 'pslide-old.py', 'pvideo.pyc', 'audio.pyc', 
'paudio.py', '__init__.py', 'pslide.py', 'audio.py', 'pslide-old2.py', 
'housekeeping.pyc', 'pslide-old.pyc', 'pslide.pyc', 'main.py', 'select.pyc', 
'__init__.pyc', 'paudio.pyc', 'housekeeping.py', 'select.py', 'pvideo.py', 
'pygame-pjc-interned-gdb', 'main.pyc']
Fatal Python error: Inconsistent interned string state.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7d346c0 (LWP 3112)]
0xb7d61456 in raise () from /lib/libc.so.6
(gdb) where
#0  0xb7d61456 in raise () from /lib/libc.so.6
#1  0xb7d62e08 in abort () from /lib/libc.so.6
#2  0xb7fce5b9 in Py_FatalError () from /usr/lib/libpython2.6.so.1.0
#3  0xb7f57291 in ?? () from /usr/lib/libpython2.6.so.1.0
#4  0xb80017d8 in ?? () from /usr/lib/libpython2.6.so.1.0
#5  0x0006 in ?? ()
#6  0xb7d35158 in ?? ()
#7  0xb7f5723a in ?? () from /usr/lib/libpython2.6.so.1.0
#8  0xb801b548 in ?? () from /usr/lib/libpython2.6.so.1.0
#9  0x08398dc0 in ?? ()
#10 0xbfe760f8 in ?? ()
#11 0xb7f497ca in PyDict_GetItemString () from /usr/lib/libpython2.6.so.1.0
Backtrace stopped: frame did not save the PC
(gdb)


>
> Another one you could try is this:
> python -m pygame.tests.__main__
>

Hmm, crashed and burnt - *when run in the directory /root/pmedia*.

bash-3.1# python -m pygame.tests.__main__   
   
skipping pygame.tests.cdrom_test (tag 'interactive')
   
skipping pygame.tests.movie_test (tag 'subprocess_ignore')  
   
housekeeping
   
select  
   
loading pygame.tests.base_test  
   
Traceback (most recent call last):  
   
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main  
   
"__main__", fname, loader, pkg_name)
   
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code 
   
exec code in run_globals
   
  File "/usr/lib/python2.6/site-packages/pygame

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[René Dudfield]

Hi,

thanks for all that testing!

if you could type 'where' after your program crashes in gdb, that
shows a stack trace(or attempts to show a stack trace).  That should
show us where the problem is.


Another one you could try is this:
python -m pygame.tests.__main__

Are you using any other modules apart from pygame?  Since pygame
displays that error message, even though the crash is caused by other
modules.


cheers,


On Thu, Sep 10, 2009 at 10:03 PM, Peter Chant wrote:
> On Thursday 10 September 2009, René Dudfield wrote:
>
>> to debug it, people would need some code to try and reproduce it.
>
> René, sorry, I'm not really a C hacker so I'm not quite sure what you'd want.
> Sample code could be tricky.  The machine where I developed the code runs it
> without issue.  It only falls over when installed on my media PC running
> Slackware 13.0 32 bit, and a virtualbox machine running the same OS.  64 bit
> slack and 12.2 32 bit slack is fine.  For that reason I don't know what the
> problematic line of code is that causes the error.
>
>>
>> Do example programs work?
>> eg.
>> python -m pygame.examples.chimp
>>
>
> chimp OK
> aliens OK
> arraydemo OK
> blend_fill OK
> blit_blends OK
> camera - no camera!
> chimp OK
> cursors - bit confused by that one, but no crash
> eventlist OK
> fastevents OK
> fonty ABORTED
> glcube OK
> headless_no_window - not sure, think it wants and image
> liquid OK
> mask - no images available to test
> midi - don't think I have midi running on test virtual machine
> moveit OK
> movieplayer - no movies on virtual machine
> oldalien OK
> overlay - don't understand demo
> pixelarray OK
> scaletest - no images to scale
> scrap_clipboard - don't understand example
> scroll OK
> sound - example did not complain, but I have not got sound on virtual machine
> sound_array_demos - ditto
> stars OK
> testsprite OK
> vgrade - This example requires Numeric and the pygame surfarray module
>
> No failures like the one I am seeing.  Happy to re-run the tests that I did
> not manage to do in the quick run through above.
>
>
>
>> Have you run it with gdb?  Is there a stack trace?
>> $ gdb python
>> (gdb) run main.py
>> (gdb) where
>>
>
> Here we go.  Had to modify script slightly to stop it going fullscreen and
> locking me out, but that makes no difference to the crash I beleive.  Not sure
> if this helps.
>
> (gdb) run pslide.py
> Starting program: /usr/bin/python pslide.py
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [New Thread 0xb7c596c0 (LWP 3119)]
> (no debugging symbols found)
> (no debugging symbols found)
> housekeeping
> select
> __main__
> [New Thread 0xb7303b90 (LWP 3120)]
> [New Thread 0xb6ac5b90 (LWP 3121)]
> Output:  . ['pslide-old2.pyc', 'pslide-old.py', 'pvideo.pyc', 'audio.pyc',
> 'paudio.
> py', '__init__.py', 'pslide.py', 'audio.py', 'pslide-old2.py',
> 'housekeeping.pyc',
> 'pslide-old.pyc', 'pslide.pyc', 'main.py', 'select.pyc', '__init__.pyc',
> 'paudio.py
> c', 'housekeeping.py', 'select.py', 'pvideo.py', 'main.pyc']
> Fatal Python error: Inconsistent interned string state.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb7c596c0 (LWP 3119)]
> 0xb7c86456 in raise () from /lib/libc.so.6
> (gdb)
>
>
>
>
> --
> Peter Chant
> http://www.petezilla.co.uk
>

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Thursday 10 September 2009, Peter Chant wrote:
> On Thursday 10 September 2009, René Dudfield wrote:
> > to debug it, people would need some code to try and reproduce it.
>
> René, sorry, I'm not really a C hacker so I'm not quite sure what you'd
> want. Sample code could be tricky.  The machine where I developed the code
> runs it without issue.  It only falls over when installed on my media PC
> running Slackware 13.0 32 bit, and a virtualbox machine running the same
> OS.  64 bit slack and 12.2 32 bit slack is fine.  For that reason I don't
> know what the problematic line of code is that causes the error.
>

By reference ot C hacker I meant I'm not any good with gdb!  I can of course 
supply my code in an egg, but there is too much to put here.


> Fatal Python error: Inconsistent interned string state.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb7c596c0 (LWP 3119)]
> 0xb7c86456 in raise () from /lib/libc.so.6
> (gdb)

If glibc is relevent I note that slack 13.0 is using the following source for 
libc (I think):

glibc-2.9-20090316.tar.bz2

Pete


-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Thursday 10 September 2009, René Dudfield wrote:

> to debug it, people would need some code to try and reproduce it.

René, sorry, I'm not really a C hacker so I'm not quite sure what you'd want.  
Sample code could be tricky.  The machine where I developed the code runs it 
without issue.  It only falls over when installed on my media PC running 
Slackware 13.0 32 bit, and a virtualbox machine running the same OS.  64 bit 
slack and 12.2 32 bit slack is fine.  For that reason I don't know what the 
problematic line of code is that causes the error.

>
> Do example programs work?
> eg.
> python -m pygame.examples.chimp
>

chimp OK
aliens OK
arraydemo OK
blend_fill OK
blit_blends OK
camera - no camera!
chimp OK
cursors - bit confused by that one, but no crash
eventlist OK
fastevents OK
fonty ABORTED
glcube OK 
headless_no_window - not sure, think it wants and image
liquid OK
mask - no images available to test
midi - don't think I have midi running on test virtual machine
moveit OK
movieplayer - no movies on virtual machine
oldalien OK
overlay - don't understand demo
pixelarray OK
scaletest - no images to scale
scrap_clipboard - don't understand example
scroll OK
sound - example did not complain, but I have not got sound on virtual machine
sound_array_demos - ditto
stars OK
testsprite OK
vgrade - This example requires Numeric and the pygame surfarray module

No failures like the one I am seeing.  Happy to re-run the tests that I did 
not manage to do in the quick run through above.



> Have you run it with gdb?  Is there a stack trace?
> $ gdb python
> (gdb) run main.py
> (gdb) where
>

Here we go.  Had to modify script slightly to stop it going fullscreen and 
locking me out, but that makes no difference to the crash I beleive.  Not sure 
if this helps. 

(gdb) run pslide.py
Starting program: /usr/bin/python pslide.py
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[New Thread 0xb7c596c0 (LWP 3119)]
(no debugging symbols found)
(no debugging symbols found)
housekeeping
select
__main__
[New Thread 0xb7303b90 (LWP 3120)]
[New Thread 0xb6ac5b90 (LWP 3121)]
Output:  . ['pslide-old2.pyc', 'pslide-old.py', 'pvideo.pyc', 'audio.pyc', 
'paudio.
py', '__init__.py', 'pslide.py', 'audio.py', 'pslide-old2.py', 
'housekeeping.pyc',
'pslide-old.pyc', 'pslide.pyc', 'main.py', 'select.pyc', '__init__.pyc', 
'paudio.py
c', 'housekeeping.py', 'select.py', 'pvideo.py', 'main.pyc']
Fatal Python error: Inconsistent interned string state.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7c596c0 (LWP 3119)]
0xb7c86456 in raise () from /lib/libc.so.6
(gdb)




-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[René Dudfield]

hi,

to debug it, people would need some code to try and reproduce it.

Do example programs work?
eg.
python -m pygame.examples.chimp


Have you run it with gdb?  Is there a stack trace?
$ gdb python
(gdb) run main.py
(gdb) where



cheers,

On Wed, Sep 9, 2009 at 7:15 PM, Peter Chant wrote:
> On Saturday 05 September 2009, Peter Chant wrote:
>
>>
>> Fatal Python error: Inconsistent interned string state.
>
> I've also reproduced this by installing my app on a fresh installation of
> Slackware 13.0 32 bit running on VirtualBox.
>
> Pete
>
>
> --
> Peter Chant
> http://www.petezilla.co.uk
>

Re: [pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

On Saturday 05 September 2009, Peter Chant wrote:

>
> Fatal Python error: Inconsistent interned string state.

I've also reproduced this by installing my app on a fresh installation of 
Slackware 13.0 32 bit running on VirtualBox.

Pete


-- 
Peter Chant
http://www.petezilla.co.uk

[pygame] pygame parachute and inconsistent interned sting state - but only on Slackware 13.0 32 bit

[Peter Chant]

Any thoughts on how to resolve this one:

Application I am producing, works fine on Slackware 12.2 (32 bit), Slackware 
13.0 (64 bit) but when running on Slackware 13.0 32 bit I get the following, 
depending on what parts of the application I call:

more pygame_error*   (2 files with errors in)
::
pygame_error1
::
Fatal Python error: (pygame parachute) Segmentation Fault
::
pygame_error2
::
Fatal Python error: Inconsistent interned string state.


Note, I am building the application using setuptools, so I can call bits 
different ways.  


Python is version 2.6.2 and pygame is pygame-1.9.1release.

Note, firstly setuptools automagically installed pygame, but when I had 
problems I downloaded it and built it to see if that made a difference.

Pete

-- 
Peter Chant
http://www.petezilla.co.uk