Hi superiors, I used OpenOffice(version3.1.0, in Linux RedHat) to convert document from .doc format into .html format. I started off by downloading and installing the SDK using the following guide.
http://wiki.services.openoffice.org/wik ... stallation<http://wiki.services.openoffice.org/wiki/SDKInstallation> Next I started to write my application using the following guide. http://wiki.services.openoffice.org/wik ... rogramming<http://wiki.services.openoffice.org/wiki/Calc/API/Programming>. And the connection to openoffice.org was successful. And I had written the catch to handle all the exception as below: int DocTranscode::doConvert( int docIndex ) { Reference<XStorable> ooStore (ooComponent, UNO_QUERY); Sequence<PropertyValue> storeProps(1); ... try{ ooStore->storeToURL( OUString::createFromAscii(strOOPathFile), storeProps ); }catch(...) // catch all the exception { handleException(); return E_GEN_ERR; ... } It runs well when the .doc document is normal. The problem I'm having is that when I am doing the stability test, I constructed a new abnormal .doc document with some wildcat string such as "&(()))^%$$", the API function "XStorable::storeToURL" would not throw any exception but just core dumped, it seems it had used some invaild memory in the function "XStorable::storeToURL", and I tried to trace the exception via the core file, but unfortunately, I could not go deep into the function XStorable::storeToURL. But I found that, the position in momery where the core dump happen as: bash-3.1$ gdb --core=core.2719 GNU gdb Red Hat Linux (6.5-16.el5rh) Copyright (C) 2006 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 "i386-redhat-linux-gnu". (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `./BasicTest'. Program terminated with signal 11, Segmentation fault. #0 0x00ac910d in ?? () (gdb) bt #0 0x00ac910d in ?? () #1 0xbfac28c4 in ?? () #2 0xbfac2a42 in ?? () #3 0x00000000 in ?? () And I disassemble the function "DocTranscode::doConvert" which I wrote via the gdb, as below: 0x00ac90c9 <_ZN12DocTranscode9doConvertEi+1241>: call 0xac42cc <_zn5woaim12tracemanager9traceinfoerkssjjns_8severityes2_irkst19basic_ostringstreamicst11char_traitsicesai...@plt> 0x00ac90ce <_ZN12DocTranscode9doConvertEi+1246>: mov 0xffffffc4(%ebp),%esi 0x00ac90d1 <_ZN12DocTranscode9doConvertEi+1249>: sub $0xc,%esi 0x00ac90d4 <_ZN12DocTranscode9doConvertEi+1252>: cmp 0xffffffe8(%ebx),%esi 0x00ac90da <_ZN12DocTranscode9doConvertEi+1258>: jne 0xac9759 <_ZN12DocTranscode9doConvertEi+2921> 0x00ac90e0 <_ZN12DocTranscode9doConvertEi+1264>: mov 0xffffffc0(%ebp),%esi 0x00ac90e3 <_ZN12DocTranscode9doConvertEi+1267>: sub $0xc,%esi 0x00ac90e6 <_ZN12DocTranscode9doConvertEi+1270>: cmp %esi,0xffffffe8(%ebx) 0x00ac90ec <_ZN12DocTranscode9doConvertEi+1276>: jne 0xac97e6 <_ZN12DocTranscode9doConvertEi+3062> 0x00ac90f2 <_ZN12DocTranscode9doConvertEi+1282>: mov 0xfffffe54(%ebp),%eax 0x00ac90f8 <_ZN12DocTranscode9doConvertEi+1288>: mov %eax,(%esp) 0x00ac90fb <_ZN12DocTranscode9doConvertEi+1291>: call 0xac424c <_znst19basic_ostringstreamicst11char_traitsicesaiceed...@plt> 0x00ac9100 <_ZN12DocTranscode9doConvertEi+1296>: mov 0xfffffe60(%ebp),%edx 0x00ac9106 <_ZN12DocTranscode9doConvertEi+1302>: movl $0x0,0xffffffac(%ebp) 0x00ac910d <_ZN12DocTranscode9doConvertEi+1309>: mov (%edx),%eax 0x00ac910f <_ZN12DocTranscode9doConvertEi+1311>: mov 0x8(%ebp),%edx 0x00ac9112 <_ZN12DocTranscode9doConvertEi+1314>: mov 0x20(%eax),%esi 0x00ac9115 <_ZN12DocTranscode9doConvertEi+1317>: mov 0x30(%edx),%eax 0x00ac9118 <_ZN12DocTranscode9doConvertEi+1320>: mov %eax,0x4(%esp) 0x00ac911c <_ZN12DocTranscode9doConvertEi+1324>: mov 0xfffffe50(%ebp),%eax 0x00ac9122 <_ZN12DocTranscode9doConvertEi+1330>: mov %eax,(%esp) 0x00ac9125 <_ZN12DocTranscode9doConvertEi+1333>: call 0xac40cc <rtl_ustring_newfromas...@plt> And I had tried many times to process this scenario, it always happened in that position. Would you have any ideas for this issue? :super: Because this issue was emergent to me :crazy: , any information about this problem was highly appreciate! Thanks very much! Best wishes Have a nice day Paries Luo GuoPei
