[gdal-dev] Re: strange behaviour of the python bindings in a seldom case

[Matthieu Rigal]

Hi all,

Sorry for the unnecessary mail to the already very full contribution list...
It also crashes after a second call to any other module...
So somehow, my accessor let any python module run 2 commands and crash at the 
third... o_O

Still very strange, but on my side, no problem with GDAL here...

Sorry again,
Regards,
Matthieu

On Monday 28 March 2011 17:53:47 Matthieu Rigal wrote:
> Dear GDAL heroes,
> 
> I have encountered a very strange behaviour of the python bindings. I am
> using version 1.7.3 with Python 2.6 on a OpenSuse 11 64bits.
> 
> We developped an in-house C++ python accessor and I get a segmentation
> fault at a very bizarre place.
> 
> I am launching following minimal python script :
> #!/usr/local/bin/python
> import sys
> from osgeo import gdal, ogr
> print sys.argv
> 
> if I launch it from this minimal shell script, everything goes fine :
> python sample1.py 1
> python sample1.py 2
> 
> But if I launch it through our C++ accessor, I got systematically a
> "segmentation fault" WHEN CALLING THE SCRIPT A SECOND TIME, that is located
> at the import step.
> 
> Stranger, if I replace the double load "gdal, ogr", by gdal or ogr, the
> scripts are working as many as I want !!! (gdal+osr crashes also, whereas
> ogr+osr does not !)
> 
> It crashes only at the second run when loading gdal AND ogr... and trying
> to repeat the error via a shellscript or via inline commands does not
> point the same problems...
> 
> I tried to use the sys.modules.items() to see if still some modules were
> present, I tried to use the reload() for the modules and I could not solve
> the problem...
> 
> The fact that it is crashing only from our launcher could indicate that
> here comes the error from, but I could not find anything... maybe I could
> run a "clean loaded module" command on the C++/Python interface, which I
> did not found now...
> (The C++/interface is a part of a much bigger processing pacakage,
> therefore I can not give easily a sample)
> 
> But also, the fact that this only occurs with >1 osgeo packages (I tried
> several other ones) indicates that there might be a problem on this side,
> or am I wrong ?
> 
> Any help or hint on something I could have forgotten would be appreciated !
> 
> Best Regards,
> Matthieu Rigal


-- 
Matthieu Rigal
Product Development

RapidEye AG                           Tel:  +49-(0)3381-89 04 331
Molkenmarkt 30                       Fax: +49-(0)3381-89 04 101
14776 Brandenburg/Havel
Germany                                  http://www.rapideye.de

RapidEye AG
Molkenmarkt 30
14776 Brandenburg an der Havel
Germany
 
Follow us on Twitter! www.twitter.com/rapideye_ag
 
Head Office/Sitz der Gesellschaft: Brandenburg an der Havel
Management Board/Vorstand: Wolfgang G. Biedermann,
                           Frederik Jung-Rothenhaeusler
Chairman of Supervisory Board/Vorsitzender des Aufsichtsrates: 
Juergen Breitkopf 
Commercial Register/Handelsregister Potsdam HRB 17 796
Tax Number/Steuernummer: 048/100/00053
VAT-Ident-Number/Ust.-ID: DE 199331235
DIN EN ISO 9001 certified
 
*************************************************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
 
The information in this e-mail is intended for the named recipients
only. It may contain privileged and confidential information. If you
have received this communication in error, any use, copying or
dissemination of its contents is strictly prohibited. Please erase all
copies of the message along with any included attachments and notify
RapidEye AG or the sender immediately by telephone at the number
indicated on this page.