Re: Core dump revisited
Nick Craig-Wood skrev:
> Sheldon <[EMAIL PROTECTED]> wrote:
> > Man. You are good. This is most insight I have had from anyone.
>
> :-)
>
> > I did initialize the arrays with PyObjects and today, after hours of
> > debugging and now with your insight, I think the problem lies here:
>
> Good!
>
> You need to release some python references otherwise you'll have a
> memory leak and copy some strings you don't own
>
> It is worth reading the definitions for those functions in the Python
> API docs
>
> http://docs.python.org/api/api.html
>
> In particular read about reference counts.
>
> With the Python C API you have to know at all time (by reading the
> doc) whether you own the reference or not, and whether you own the
> memory or not.
>
> > /* here a python list of strings is read into a C string array */
> > static int readPythonObject(void) {
> >
> >int i;
> >PyObject *msgop;
> >PyObject *ppsop;
> >PyObject *tileop;
> >PyObject *sceneop;
> >
> >for (i = 0; i < work.sumscenes; i++) {
> > msgop = PyList_GetItem(work.msgobj, i);
> > work.msg_scenes[i] = PyString_AsString(msgop);
>
>work.msg_scenes[i] = strdup(PyString_AsString(msgop));
>Py_DECREF(msgop);
>
> > ppsop = PyList_GetItem(work.ppsobj, i);
> > work.pps_scenes[i] = PyString_AsString(ppsop);
>
> work.pps_scenes[i] = strdup(PyString_AsString(ppsop));
> Py_DECREF(ppsop);
>
> >}
> >for (i = 0; i < NumberOfTiles; i++) {
> > tileop = PyList_GetItem(work.tileobj, i);
> > work.tiles[i] = PyString_AsString(tileop);
>
>work.tiles[i] = strdup(PyString_AsString(tileop));
>Py_DECREF(tileop);
>
> > sceneop = PyList_GetItem(work.nscenesobj, i);
> > work.nscenes[i] = PyInt_AsLong(sceneop);
>
> Py_DECREF(sceneop);
>
> >}
> >return 1;
> > } /*end readPythonObject*/
>
> You free() the strings later which is fine.
>
> The above ignores errors which PyList_GetItem may return and strdup()
> returning 0, but it should get you out of trouble hopefully.
>
> ...
>
> I've written lots of quite similar code, here is a snippet. Note the
> comments about who owns the reference, and the error checking. Also
> note xstrdup() which is a strdup() which blows up if no memory is
> available.
>
> [snip]
> PyObject *item = PySequence_GetItem(value, i); /* real ref */
> if (item == 0)
> {
> fprintf(stderr, "Failed to read '%s[%d]' attribute\n", name, i);
> goto err;
> }
> item_cstr = PyString_AsString(item); /* borrowed */
> if (item_cstr == 0)
> {
> fprintf(stderr, "Failed to read '%s[%d]' as string\n", name, i);
> goto err;
> }
> label[i] = xstrdup(item_cstr);
> Py_DECREF(item);
> item = 0;
> [snip]
> err:;
> PyErr_Print();
> out:;
> if (value)
> Py_DECREF(value);
> if (item)
> Py_DECREF(item);
> return rc;
>
>
> --
> Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
Thanks Nick! Man, I really appreciate this. I did dereference before
but the program crashed and I did understand why so I kept on learning.
Now I have your snip. Much obliged.
I will be adding Numpy to my new PC in Jan and there I can pass arrays
instead of list. Still, I would like to save your email address i case
I have some mre questions later - if that ok with you?
I will make the changes and try to run the code.
/S
--
http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Sheldon <[EMAIL PROTECTED]> wrote:
> Man. You are good. This is most insight I have had from anyone.
:-)
> I did initialize the arrays with PyObjects and today, after hours of
> debugging and now with your insight, I think the problem lies here:
Good!
You need to release some python references otherwise you'll have a
memory leak and copy some strings you don't own
It is worth reading the definitions for those functions in the Python
API docs
http://docs.python.org/api/api.html
In particular read about reference counts.
With the Python C API you have to know at all time (by reading the
doc) whether you own the reference or not, and whether you own the
memory or not.
> /* here a python list of strings is read into a C string array */
> static int readPythonObject(void) {
>
>int i;
>PyObject *msgop;
>PyObject *ppsop;
>PyObject *tileop;
>PyObject *sceneop;
>
>for (i = 0; i < work.sumscenes; i++) {
> msgop = PyList_GetItem(work.msgobj, i);
> work.msg_scenes[i] = PyString_AsString(msgop);
work.msg_scenes[i] = strdup(PyString_AsString(msgop));
Py_DECREF(msgop);
> ppsop = PyList_GetItem(work.ppsobj, i);
> work.pps_scenes[i] = PyString_AsString(ppsop);
work.pps_scenes[i] = strdup(PyString_AsString(ppsop));
Py_DECREF(ppsop);
>}
>for (i = 0; i < NumberOfTiles; i++) {
> tileop = PyList_GetItem(work.tileobj, i);
> work.tiles[i] = PyString_AsString(tileop);
work.tiles[i] = strdup(PyString_AsString(tileop));
Py_DECREF(tileop);
> sceneop = PyList_GetItem(work.nscenesobj, i);
> work.nscenes[i] = PyInt_AsLong(sceneop);
Py_DECREF(sceneop);
>}
>return 1;
> } /*end readPythonObject*/
You free() the strings later which is fine.
The above ignores errors which PyList_GetItem may return and strdup()
returning 0, but it should get you out of trouble hopefully.
...
I've written lots of quite similar code, here is a snippet. Note the
comments about who owns the reference, and the error checking. Also
note xstrdup() which is a strdup() which blows up if no memory is
available.
[snip]
PyObject *item = PySequence_GetItem(value, i); /* real ref */
if (item == 0)
{
fprintf(stderr, "Failed to read '%s[%d]' attribute\n", name, i);
goto err;
}
item_cstr = PyString_AsString(item); /* borrowed */
if (item_cstr == 0)
{
fprintf(stderr, "Failed to read '%s[%d]' as string\n", name, i);
goto err;
}
label[i] = xstrdup(item_cstr);
Py_DECREF(item);
item = 0;
[snip]
err:;
PyErr_Print();
out:;
if (value)
Py_DECREF(value);
if (item)
Py_DECREF(item);
return rc;
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
--
http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
"Sheldon" <[EMAIL PROTECTED]> wrote: > > Duncan Booth skrev: > >> "Sheldon" <[EMAIL PROTECTED]> wrote: >> >> > I am new to this and copied this code from a colleague. So, it >> > corrupts the pointer. How do I do this properly? >> > >> Here is at least part of your problem: >> >> msgop = PyList_GetItem(work.msgobj, i); >> work.msg_scenes[i] = PyString_AsString(msgop); >> ppsop = PyList_GetItem(work.ppsobj, i); >> work.pps_scenes[i] = PyString_AsString(ppsop); >> ... >> free(work.pps_scenes[i]); >> free(work.msg_scenes[i]); >> >> You initialised msg_scenes and pps_scenes with a malloc'ed block but >> you then just overwrote the pointer with the result of >> PyString_AsString. You don't own the memory for the string returned >> from PyString_AsString, so freeing it will cause a corruption. You >> should copy the string data into the malloc'ed block (with >> appropriate length checks). > > Do you mean with: PyString_FromStringAndSize() and > PyString_Size(PyObject *string) > If you wish, or even just strlen() if you aren't concerned about embedded nulls. -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Duncan Booth skrev: > "Sheldon" <[EMAIL PROTECTED]> wrote: > > > I am new to this and copied this code from a colleague. So, it > > corrupts the pointer. How do I do this properly? > > > Here is at least part of your problem: > > msgop = PyList_GetItem(work.msgobj, i); > work.msg_scenes[i] = PyString_AsString(msgop); > ppsop = PyList_GetItem(work.ppsobj, i); > work.pps_scenes[i] = PyString_AsString(ppsop); > ... > free(work.pps_scenes[i]); > free(work.msg_scenes[i]); > > You initialised msg_scenes and pps_scenes with a malloc'ed block but you > then just overwrote the pointer with the result of PyString_AsString. You > don't own the memory for the string returned from PyString_AsString, so > freeing it will cause a corruption. You should copy the string data into > the malloc'ed block (with appropriate length checks). Do you mean with: PyString_FromStringAndSize() and PyString_Size(PyObject *string) /S -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
"Sheldon" <[EMAIL PROTECTED]> wrote: > I am new to this and copied this code from a colleague. So, it > corrupts the pointer. How do I do this properly? > Here is at least part of your problem: msgop = PyList_GetItem(work.msgobj, i); work.msg_scenes[i] = PyString_AsString(msgop); ppsop = PyList_GetItem(work.ppsobj, i); work.pps_scenes[i] = PyString_AsString(ppsop); ... free(work.pps_scenes[i]); free(work.msg_scenes[i]); You initialised msg_scenes and pps_scenes with a malloc'ed block but you then just overwrote the pointer with the result of PyString_AsString. You don't own the memory for the string returned from PyString_AsString, so freeing it will cause a corruption. You should copy the string data into the malloc'ed block (with appropriate length checks). -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Nick Craig-Wood skrev:
> Sheldon <[EMAIL PROTECTED]> wrote:
> > Sheldon skrev:
> > > Wonderful! Now I know how to used gdb with python.
>
> Good!
>
> > > The are results area posted below. Since I am new at this I could
> > > used some help in interpreting the problem. What I do know is
> > > this: my allocation of the array is good but when freeing the
> > > array, a problem arises. The problem is given below but since I am
> > > new as well to C
>
> Ambitious!
>
> > > I sure could use some help.
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 1077321856 (LWP 32710)]
> > > 0x40297b83 in mallopt () from /lib/tls/libc.so.6
> > > (gdb) bt
> > > #0 0x40297b83 in mallopt () from /lib/tls/libc.so.6
> > > #1 0x402958ba in free () from /lib/tls/libc.so.6
> > > #2 0x405e070a in MemoryFreeOrd () at msgppsmodule_area.c:1675
> > > #3 0x405dae0a in msgppsarea (self=0x0, args=0x4042aa7c, kwargs=0x0) at
> > > msgppsmodule_area.c:328
> > > #4 0x40073b16 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0
>
> Typing "up" and "down" to move up and down the call stack is a good
> thing. Type "l" to see a list of code at the point that things went
> wrong.
>
> You can type "print " to see the values of variables.
> gdb understands most C syntax so you can use "print
> this->member[1].data" etc.
>
> This all assumes you compiled and linked with debugging (-g flag to
> compiler and linker). Turning off optimisation may make the debugger
> more accurate also.
>
> I can't tell exactly where your program crashed because of line
> wrapping it your post, but is it certainly within MemoryFreeOrd().
>
> What I would do next is run the program under gdb, wait for it to
> crash then print the values of things in the MemoryFreeOrd() function.
> You'll find one of the pointers has been corrupted, ie doesn't point
> to valid memory or memory allocated with malloc() I expect. 0 or NULL
> is an acceptable input to most free() implementations but not all.
>
> Finding out exactly where that pointer got corrupted is harder. Maybe
> it was never initialised, or maybe you initialised it with a PyObject
> or maybe you have a memory scribble somewhere.
>
> A memory scribble is the hardest bug to find because it happened
> elsewhere in your program. Look at the data that was overwritten.
> Maybe it is a string you can identify... You'll also want to start
> reading the gdb manual on breakpoints and watchpoints at this moment!
>
> Find memory corruptions can be tricky and time consuming.
>
> Valgrind can help also.
>
> Good luck!
> --
> Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
Man. You are good. This is most insight I have had from anyone. I did
initialize the arrays with PyObjects and today, after hours of
debugging and now with your insight, I think the problem lies here:
/* here a python list of strings is read into a C string array */
static int readPythonObject(void) {
int i;
PyObject *msgop;
PyObject *ppsop;
PyObject *tileop;
PyObject *sceneop;
for (i = 0; i < work.sumscenes; i++) {
msgop = PyList_GetItem(work.msgobj, i);
work.msg_scenes[i] = PyString_AsString(msgop);
ppsop = PyList_GetItem(work.ppsobj, i);
work.pps_scenes[i] = PyString_AsString(ppsop);
}
for (i = 0; i < NumberOfTiles; i++) {
tileop = PyList_GetItem(work.tileobj, i);
work.tiles[i] = PyString_AsString(tileop);
sceneop = PyList_GetItem(work.nscenesobj, i);
work.nscenes[i] = PyInt_AsLong(sceneop);
}
return 1;
} /*end readPythonObject*/
I am new to this and copied this code from a colleague. So, it corrupts
the pointer. How do I do this properly?
Your help is truly appreciated!
/S
--
http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Sheldon wrote: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1077321856 (LWP 32710)] > 0x40297b83 in mallopt () from /lib/tls/libc.so.6 > (gdb) bt > #0 0x40297b83 in mallopt () from /lib/tls/libc.so.6 > #1 0x402958ba in free () from /lib/tls/libc.so.6 > #2 0x405e070a in MemoryFreeOrd () at msgppsmodule_area.c:1675 > #3 0x405dae0a in msgppsarea (self=0x0, args=0x4042aa7c, kwargs=0x0) at > msgppsmodule_area.c:328 > #4 0x40073b16 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0 > >From my experience, segmentation faults in malloc/free is usually the result of memory corruption. My experience comes mostly from solaris and I realize the memory allocator might work differently in Linux, but that would be my guess. The cause for memory corruption can be writing outside arrays, using deallocated memory or something like that. Under Linux, there are tools like valgrind (free), electric fence (free), purify (not for free last time I checked) and probably a few more, that may help you track down memory corruption bugs. They are often hard to find using just a debugger. HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Sheldon <[EMAIL PROTECTED]> wrote: > Sheldon skrev: > > Wonderful! Now I know how to used gdb with python. Good! > > The are results area posted below. Since I am new at this I could > > used some help in interpreting the problem. What I do know is > > this: my allocation of the array is good but when freeing the > > array, a problem arises. The problem is given below but since I am > > new as well to C Ambitious! > > I sure could use some help. > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1077321856 (LWP 32710)] > > 0x40297b83 in mallopt () from /lib/tls/libc.so.6 > > (gdb) bt > > #0 0x40297b83 in mallopt () from /lib/tls/libc.so.6 > > #1 0x402958ba in free () from /lib/tls/libc.so.6 > > #2 0x405e070a in MemoryFreeOrd () at msgppsmodule_area.c:1675 > > #3 0x405dae0a in msgppsarea (self=0x0, args=0x4042aa7c, kwargs=0x0) at > > msgppsmodule_area.c:328 > > #4 0x40073b16 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0 Typing "up" and "down" to move up and down the call stack is a good thing. Type "l" to see a list of code at the point that things went wrong. You can type "print " to see the values of variables. gdb understands most C syntax so you can use "print this->member[1].data" etc. This all assumes you compiled and linked with debugging (-g flag to compiler and linker). Turning off optimisation may make the debugger more accurate also. I can't tell exactly where your program crashed because of line wrapping it your post, but is it certainly within MemoryFreeOrd(). What I would do next is run the program under gdb, wait for it to crash then print the values of things in the MemoryFreeOrd() function. You'll find one of the pointers has been corrupted, ie doesn't point to valid memory or memory allocated with malloc() I expect. 0 or NULL is an acceptable input to most free() implementations but not all. Finding out exactly where that pointer got corrupted is harder. Maybe it was never initialised, or maybe you initialised it with a PyObject or maybe you have a memory scribble somewhere. A memory scribble is the hardest bug to find because it happened elsewhere in your program. Look at the data that was overwritten. Maybe it is a string you can identify... You'll also want to start reading the gdb manual on breakpoints and watchpoints at this moment! Find memory corruptions can be tricky and time consuming. Valgrind can help also. Good luck! -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Nick Craig-Wood skrev: > Sheldon <[EMAIL PROTECTED]> wrote: > > gdb msgppscomp.py core.3203 > > Run > > gdb python > > Then type > > run msgppscomp.py > > at the gdb prompt. > > When it crashes, type "bt" for a back trace. This will pinpoint > exactly where it crashes. > > Hopefully that will make things clearer. If not post the output. > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick Wonderful! Now I know how to used gdb with python. The are results area posted below. Since I am new at this I could used some help in interpreting the problem. What I do know is this: my allocation of the array is good but when freeing the array, a problem arises. The problem is given below but since I am new as well to C I sure could use some help. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1077321856 (LWP 32710)] 0x40297b83 in mallopt () from /lib/tls/libc.so.6 (gdb) bt #0 0x40297b83 in mallopt () from /lib/tls/libc.so.6 #1 0x402958ba in free () from /lib/tls/libc.so.6 #2 0x405e070a in MemoryFreeOrd () at msgppsmodule_area.c:1675 #3 0x405dae0a in msgppsarea (self=0x0, args=0x4042aa7c, kwargs=0x0) at msgppsmodule_area.c:328 #4 0x40073b16 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0 I appreciate your help so far and could use some more. /S -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Nick Craig-Wood skrev: > Sheldon <[EMAIL PROTECTED]> wrote: > > gdb msgppscomp.py core.3203 > > Run > > gdb python > > Then type > > run msgppscomp.py > > at the gdb prompt. > > When it crashes, type "bt" for a back trace. This will pinpoint > exactly where it crashes. > > Hopefully that will make things clearer. If not post the output. > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick Wonderful! Now I know how to used gdb with python. The are results area posted below. Since I am new at this I could used some help in interpreting the problem. What I do know is this: my allocation of the array is good but when freeing the array, a problem arises. The problem is given below but since I am new as well to C I sure could use some help. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1077321856 (LWP 32710)] 0x40297b83 in mallopt () from /lib/tls/libc.so.6 (gdb) bt #0 0x40297b83 in mallopt () from /lib/tls/libc.so.6 #1 0x402958ba in free () from /lib/tls/libc.so.6 #2 0x405e070a in MemoryFreeOrd () at msgppsmodule_area.c:1675 #3 0x405dae0a in msgppsarea (self=0x0, args=0x4042aa7c, kwargs=0x0) at msgppsmodule_area.c:328 #4 0x40073b16 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0 I appreciate your help so far and could use some more. /S -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
Sheldon <[EMAIL PROTECTED]> wrote: > gdb msgppscomp.py core.3203 Run gdb python Then type run msgppscomp.py at the gdb prompt. When it crashes, type "bt" for a back trace. This will pinpoint exactly where it crashes. Hopefully that will make things clearer. If not post the output. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Core dump revisited
On 17 dic, 07:01, "Sheldon" <[EMAIL PROTECTED]> wrote: > I have a python script that uses a C extention. I keep getting a > recurring problem that causes a core dump a few lines after the C > extention return data back tp python. I tried using pbd and gdb but I Most probably the error is inside the C extension, not in Python code. Contact the author. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Core dump revisited
Hi, I have a python script that uses a C extention. I keep getting a recurring problem that causes a core dump a few lines after the C extention return data back tp python. I tried using pbd and gdb but I have not succeeded in understanding what went wrong and where. I post the python script here is the error message and gdb output after reading the core file: . printout from with C extention Completed freeing 2D arrays. Now freeing 1D arrays freed 1D arrays freeing 15km arrays Complete Returning data back to Python! In python: assigning tuple data to numeric arrays! Time to do the coastal effects Segmentation fault (core dumped) .. Now there next step after "Time to do the coastal effects" was never executed. And even if I put another print statement there the same thing happens. I am using python 2.3 and I have set my stacksize to unlimited. When reading the core dump file with gdb I get: gdb msgppscomp.py core.3203 GNU gdb 6.0-2mdk (Mandrake Linux) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-mandrake-linux-gnu"..."/data/proj_ns1/safworks/sheldon/msgppscomp.py": not in executable format: File format not recognized Core was generated by `python msgppscomp.py'. Program terminated with signal 11, Segmentation fault. #0 0x40079dfa in ?? () (gdb) . I am not very familiar with using gdb with python and C extentions. I would like to get some ideas about where the problem might be. I have made sure that all the arrays in the C extention are freed before exiting so I doubt that this might be the problem. Here is the python script: #!/usr/bin/env python #!-*-coding: UTF-8 -*- class WriteHdfFile: def __init__(self,outfile): self.outfile = outfile self.COMPRESS_LVL = 6 def writeAreainfo(self): import _pyhl import sys sys.float_output_precision = 2 aList = _pyhl.nodelist() aNode = _pyhl.node(_pyhl.GROUP_ID,"/PPS_MSG_COMP") aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/LAT") aNode.setArrayValue(1,lat.shape,lat,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/LON") aNode.setArrayValue(1,lon.shape,lon,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/VALCONCEN") aNode.setArrayValue(1,valconcen.shape,valconcen,"int",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/LIGHTCON") aNode.setArrayValue(1,lightcon.shape,lightcon,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/BIAS100") aNode.setArrayValue(1,bias100.shape,bias100,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/BIAS75") aNode.setArrayValue(1,bias75.shape,bias75,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/BIAS50") aNode.setArrayValue(1,bias50.shape,bias50,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/BIAS25") aNode.setArrayValue(1,bias25.shape,bias25,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/COAST") aNode.setArrayValue(1,coast.shape,coast,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/STATISTICS") aNode.setArrayValue(1,stats.shape,stats,"int",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/PERCENTAGE") aNode.setArrayValue(1,percentage.shape,percentage,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/VA_vs_BIAS") aNode.setArrayValue(1,va_area.shape,va_area,"float",-1) aList.addNode(aNode) aNode=_pyhl.node(_pyhl.DATASET_ID,"/VANUM") aNode.setArrayValue(1,vanum.shape,vanum,"float",-1) aList.addNode(aNode) aNode = _pyhl.node(_pyhl.ATTRIBUTE_ID,"/NSCENES") aNode.setScalarValue(-1,areascenes,"int",-1) aList.addNode(aNode) aNode = _pyhl.node(_pyhl.ATTRIBUTE_ID,"/SATELLITE") aNode.setScalarValue(-1,satid,"string",-1) aList.addNode(aNode) self.status = aList.write(self.outfile,self.COMPRESS_LVL) return self.status #--- if __name__ == "__main__": from Numeric import * import sys, os, string, math, glob import msgppsarea,msgppscoast import shelve date = str(200510) #date = sys.argv[1] #s= sys.argv[2] cp = 'cfc' global valconcen,bias100,bias75,lightcon,bias50,bias25,percentage,va_area,lat,lon g
