Error on svl modules

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Error on svl modules

Davide Dozza
I' finding this problem by building OOo.

This in my configure command:

$ ./configure --with-dict="ITIT,ENUS" --with-lang="it" --without-junit
--disable-build-mozilla  -with-mozilla-build="/cygdrive/c/mozilla-build"
--with-cl-home="/cygdrive/c/Programmi/Microsoft Visual Studio 9.0/VC"
--with-midl-path="/cygdrive/c/Programmi/Microsoft SDKs/Windows/v6.1/Bin"
--with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5"
--with-frame-home="/cygdrive/c/Programmi/Microsoft SDKs/Windows/v6.1"
--with-asm-home="/cygdrive/c/Programmi/Microsoft Visual Studio 9.0/VC/Bin"
--with-jdk-home="/cygdrive/c/Programmi/Java/jdk1.6.0_17"
--with-ant-home=/cygdrive/c/ooo/apache-ant-1.7.1/
--with-psdk-home="/cygdrive/c/Programmi/Microsoft SDKs/Windows/v6.1"

And this is the error:

Entering /cygdrive/c/ooo/DEV300_m81/svl/source/items

Making:    all_items.dpslo
Making:    items.dpr
Making:    items.items.dprr
Compiling: svl/source/items/aeitem.cxx
Compiling: svl/source/items/cenumitm.cxx
Compiling: svl/source/items/cintitem.cxx
Compiling: svl/source/items/cntwall.cxx
Compiling: svl/source/items/ctypeitm.cxx
Compiling: svl/source/items/custritm.cxx
Compiling: svl/source/items/dateitem.cxx
Compiling: svl/source/items/eitem.cxx
Compiling: svl/source/items/flagitem.cxx
Compiling: svl/source/items/globalnameitem.cxx
Compiling: svl/source/items/ilstitem.cxx
Compiling: svl/source/items/imageitm.cxx
Compiling: svl/source/items/intitem.cxx
Compiling: svl/source/items/itemiter.cxx
Compiling: svl/source/items/itempool.cxx
Compiling: svl/source/items/itemprop.cxx
Compiling: svl/source/items/itemset.cxx
Compiling: svl/source/items/lckbitem.cxx
Compiling: svl/source/items/macitem.cxx
Compiling: svl/source/items/poolcach.cxx
Compiling: svl/source/items/poolio.cxx
Compiling: svl/source/items/poolitem.cxx
Compiling: svl/source/items/ptitem.cxx
Compiling: svl/source/items/rectitem.cxx
Compiling: svl/source/items/rngitem.cxx
Compiling: svl/source/items/sfontitm.cxx
Compiling: svl/source/items/sitem.cxx
Compiling: svl/source/items/slstitm.cxx
Compiling: svl/source/items/srchitem.cxx
Compiling: svl/source/items/stritem.cxx
Compiling: svl/source/items/style.cxx
Compiling: svl/source/items/stylepool.cxx
Compiling: svl/source/items/szitem.cxx
Compiling: svl/source/items/visitem.cxx
Compiling: svl/source/items/whiter.cxx
Making:    items.lib
../../wntmsci12.pro/misc/svl/dummy/localize.sdf
C:/cygwin/bin/touch.exe ../../wntmsci12.pro/misc/svl/dummy/localize.sdf
Making:    cstitem.src

TransEx 3.1 Copyright 2000, 2010 Oracle and/or its affiliates. All
Rights Reserved.
================================================================================
=====
Making:    items.srs
cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
Error starting preprocessor
dmake:  Error code 1, while making '../../wntmsci12.pro/srs/items.srs'

The debugger window opens on transex3 and when I close it the
compilation stops with the error above.

Davide





signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Davide Dozza
Davide Dozza ha scritto:

[...]

> Making:    items.srs
> cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
> Error starting preprocessor
> dmake:  Error code 1, while making '../../wntmsci12.pro/srs/items.srs'
>
> The debugger window opens on transex3 and when I close it the
> compilation stops with the error above.

The windows error on debugger reports:

Unhandled exception at 0x1000fb1a (tlmi.dll) in transex3.exe:
0xC0000005: Access violation reading location 0x00000000.

Davide


signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Michael Stahl-3
On 15/06/2010 17:54, Davide Dozza wrote:

> Davide Dozza ha scritto:
>
> [...]
>
>> Making:    items.srs
>> cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
>> Error starting preprocessor
>> dmake:  Error code 1, while making '../../wntmsci12.pro/srs/items.srs'
>>
>> The debugger window opens on transex3 and when I close it the
>> compilation stops with the error above.
>
> The windows error on debugger reports:
>
> Unhandled exception at 0x1000fb1a (tlmi.dll) in transex3.exe:
> 0xC0000005: Access violation reading location 0x00000000.
>
> Davide

hmm, no idea what's the problem here.

apparently this "transex3" thing wants to execute cpp, but doesn't give it
proper arguments. then cpp returns an error, and "transex3" can't handle
that and crashes.

i guess you should file an issue about this. assign it to "ihi".

you could try to cd into the "svl" module, and then run:
build VERBOSE=1

that will hopefully be more informative.

also, maybe it's a known and fixed issue, and trying again with m82 will
make it go away.

--
"Programs must be written for people to read, and only incidentally
 for machines to execute." -- Abelson & Sussman, SICP


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Error on svl modules

Hans-Joachim Lankenau - Sun Germany - ham02 - Hamburg
hi!

On 06/16/10 11:25, Michael Stahl wrote:

> On 15/06/2010 17:54, Davide Dozza wrote:
>> Davide Dozza ha scritto:
>>
>> [...]
>>
>>> Making:    items.srs
>>> cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
>>> Error starting preprocessor
>>> dmake:  Error code 1, while making '../../wntmsci12.pro/srs/items.srs'
>>>
iirc, transex3 should be done at this point and this is an error from
rsc.exe

my bet would be a TMP variable POSIX notation. on windows TMP should
look like TMP=c:/tmpdir (volume, colon, path with slashes) to make both
sides happy: cygwin and native tools.

>>> The debugger window opens on transex3 and when I close it the
>>> compilation stops with the error above.
>> The windows error on debugger reports:
>>
>> Unhandled exception at 0x1000fb1a (tlmi.dll) in transex3.exe:
>> 0xC0000005: Access violation reading location 0x00000000.
>>
>> Davide
>
> hmm, no idea what's the problem here.
>
> apparently this "transex3" thing wants to execute cpp, but doesn't give it
> proper arguments. then cpp returns an error, and "transex3" can't handle
> that and crashes.
>
> i guess you should file an issue about this. assign it to "ihi".
>
> you could try to cd into the "svl" module, and then run:
> build VERBOSE=1
>
> that will hopefully be more informative.
>
> also, maybe it's a known and fixed issue, and trying again with m82 will
> make it go away.
>

tschau...

ause

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Error on svl modules

Davide Dozza
Hans-Joachim Lankenau - Sun Germany - ham02 - Hamburg ha scritto:

> hi!
>
> On 06/16/10 11:25, Michael Stahl wrote:
>> On 15/06/2010 17:54, Davide Dozza wrote:
>>> Davide Dozza ha scritto:
>>>
>>> [...]
>>>
>>>> Making:    items.srs
>>>> cpp: line 0, Error: Too many file arguments.  Usage: cpp [input
>>>> [output]]
>>>> Error starting preprocessor
>>>> dmake:  Error code 1, while making '../../wntmsci12.pro/srs/items.srs'
>>>>
> iirc, transex3 should be done at this point and this is an error from
> rsc.exe
>
> my bet would be a TMP variable POSIX notation. on windows TMP should
> look like TMP=c:/tmpdir (volume, colon, path with slashes) to make both
> sides happy: cygwin and native tools.
The TMP environment variable is not set while  TMPDIR points to
C:/cygwin/tmp


I tried with VERBOSE=1

This is the output *before* the debug window opens.

Making:    mediatyp.src
mkdir.exe ../../wntmsci12.pro/misc/misc/
/bin/rm -f ../../wntmsci12.pro/misc/misc/mediatyp.src
mkdir.exe -p  ../../wntmsci12.pro/misc/svl
: &&
PATH=${PATH+${PATH}:}/cygdrive/c/ooo/DEV300_m81/solver/300/wntmsci12.pr
o/bin C:/ooo/DEV300_m81/solver/300/wntmsci12.pro/bin/transex3  -p svl -i
mediaty
p.src -o ../../wntmsci12.pro/misc/misc/mediatyp.src.wntmsci12.pro -m
../../wntms
ci12.pro/misc/svl/dummy/localize.sdf -l all

TransEx 3.1 Copyright 2000, 2010 Oracle and/or its affiliates. All
Rights Reserv
ed.
================================================================================
=====


The msg error on the debug window reports:
"An unhandled win32 exception occurred in transex3.exe [496]"

after that if I select NO for debugging the building process ends with:

mv ../../wntmsci12.pro/misc/misc/mediatyp.src.wntmsci12.pro
../../wntmsci12.pro/
misc/misc/mediatyp.src
/bin/rm -f ../../wntmsci12.pro/misc/misc/mediatyp.src.wntmsci12.pro
Making:    misc.srs
: &&
PATH=${PATH+${PATH}:}/cygdrive/c/ooo/DEV300_m81/solver/300/wntmsci12.pr
o/bin slfl.pl C:/ooo/DEV300_m81/solver/300/wntmsci12.pro/bin/rsc
-presponse -ver
bose @C:/cygwin/tmp/mkfRlloJ
Preprocessor commandline:  -I. -I. -I..\..\wntmsci12.pro\inc\misc
-I..\inc -I..\
..\inc\pch -I..\..\inc -I..\..\WIN\inc -I..\..\wntmsci12.pro\inc -I.
-IC:\ooo\DE
V300_m81\solver\300\wntmsci12.pro\inc\stl
-IC:\ooo\DEV300_m81\solver\300\wntmsci
12.pro\inc\external -IC:\ooo\DEV300_m81\solver\300\wntmsci12.pro\inc
-IC:\ooo\DE
V300_m81\solenv\wntmsci12\inc -IC:\ooo\DEV300_m81\solenv\inc
-IC:\ooo\DEV300_m81
\res -IC:\ooo\DEV300_m81\solver\300\wntmsci12.pro\inc\stl
-IC:\PROGRA~1\Java\JDK
16~1.0_2\include\win32 -IC:\PROGRA~1\Java\JDK16~1.0_2\include
-IC:\PROGRA~1\MICR
OS~2\Windows\v6.1\include -IC:\PROGRA~1\MICROS~1.0\VC\include
-IC:\PROGRA~1\MICR
OS~1.0SD\include -IC:\PROGRA~1\MICROS~1.0SD\include
-IC:\ooo\DEV300_m81\solver\3
00\wntmsci12.pro\inc\offuh -I. -I..\..\res -I. -DWNT -DNT351 -DMSC
-DM1500 -DSOL
AR_JAVA -DFULL_DESK -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0
-DUPDVER="300m81(Buil
d:9509)" ..\..\wntmsci12.pro\misc\misc\mediatyp.src C:\Documents and
Settings\ut
ente1\AAC.tmp
Preprocessor startline:
C:/ooo/DEV300_m81/solver/300/wntmsci12.pro/bin/rscpp @C
:\Documents and Settings\utente1\AAD.tmp
cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
Error starting preprocessor
dmake:  Error code 1, while making '../../wntmsci12.pro/srs/misc.srs'

Davide


signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Michael Stahl-3
On 16/06/2010 18:01, Davide Dozza wrote:

> Hans-Joachim Lankenau - Sun Germany - ham02 - Hamburg ha scritto:
>> hi!
>>
>> On 06/16/10 11:25, Michael Stahl wrote:
>>> On 15/06/2010 17:54, Davide Dozza wrote:
>>>> Davide Dozza ha scritto:
>>>>
>>>> [...]
>>>>
>>>>> Making:    items.srs
>>>>> cpp: line 0, Error: Too many file arguments.  Usage: cpp [input
>>>>> [output]]
>>>>> Error starting preprocessor
>>>>> dmake:  Error code 1, while making '../../wntmsci12.pro/srs/items.srs'
>>>>>
>> iirc, transex3 should be done at this point and this is an error from
>> rsc.exe
>>
>> my bet would be a TMP variable POSIX notation. on windows TMP should
>> look like TMP=c:/tmpdir (volume, colon, path with slashes) to make both
>> sides happy: cygwin and native tools.
>
> The TMP environment variable is not set while  TMPDIR points to
> C:/cygwin/tmp

AFAIK $TMPDIR should be used then, it's the standard.

> I tried with VERBOSE=1
>
> This is the output *before* the debug window opens.
>
> Making:    mediatyp.src
> mkdir.exe ../../wntmsci12.pro/misc/misc/
> /bin/rm -f ../../wntmsci12.pro/misc/misc/mediatyp.src
> mkdir.exe -p  ../../wntmsci12.pro/misc/svl
> : &&
> PATH=${PATH+${PATH}:}/cygdrive/c/ooo/DEV300_m81/solver/300/wntmsci12.pr
> o/bin C:/ooo/DEV300_m81/solver/300/wntmsci12.pro/bin/transex3  -p svl -i
> mediaty
> p.src -o ../../wntmsci12.pro/misc/misc/mediatyp.src.wntmsci12.pro -m
> ../../wntms
> ci12.pro/misc/svl/dummy/localize.sdf -l all
>
> TransEx 3.1 Copyright 2000, 2010 Oracle and/or its affiliates. All
> Rights Reserv
> ed.
> ================================================================================
> =====
>
>
> The msg error on the debug window reports:
> "An unhandled win32 exception occurred in transex3.exe [496]"

so indeed "transex3" is buggy.
please try to get a backtrace to see what's going on exactly.
probably you need to compile "transex3" with debug, and also the "tools"
module:
> cd tools && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver
> cd transex && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver

(i hope that should put unstripped libraries in the solver, but haven't
tried it.  if it strips anyway, copy the libraries...)

when you have a good backtrace, you can file an issue.
for bonus points, try to figure out how to fix it yourself if you like,
and attach a patch.

> after that if I select NO for debugging the building process ends with:
>
> mv ../../wntmsci12.pro/misc/misc/mediatyp.src.wntmsci12.pro
> ../../wntmsci12.pro/
> misc/misc/mediatyp.src
> /bin/rm -f ../../wntmsci12.pro/misc/misc/mediatyp.src.wntmsci12.pro
> Making:    misc.srs
> : &&
> PATH=${PATH+${PATH}:}/cygdrive/c/ooo/DEV300_m81/solver/300/wntmsci12.pr
> o/bin slfl.pl C:/ooo/DEV300_m81/solver/300/wntmsci12.pro/bin/rsc
> -presponse -ver
> bose @C:/cygwin/tmp/mkfRlloJ
> Preprocessor commandline:  -I. -I. -I..\..\wntmsci12.pro\inc\misc
> -I..\inc -I..\
> ..\inc\pch -I..\..\inc -I..\..\WIN\inc -I..\..\wntmsci12.pro\inc -I.
> -IC:\ooo\DE
> V300_m81\solver\300\wntmsci12.pro\inc\stl
> -IC:\ooo\DEV300_m81\solver\300\wntmsci
> 12.pro\inc\external -IC:\ooo\DEV300_m81\solver\300\wntmsci12.pro\inc
> -IC:\ooo\DE
> V300_m81\solenv\wntmsci12\inc -IC:\ooo\DEV300_m81\solenv\inc
> -IC:\ooo\DEV300_m81
> \res -IC:\ooo\DEV300_m81\solver\300\wntmsci12.pro\inc\stl
> -IC:\PROGRA~1\Java\JDK
> 16~1.0_2\include\win32 -IC:\PROGRA~1\Java\JDK16~1.0_2\include
> -IC:\PROGRA~1\MICR
> OS~2\Windows\v6.1\include -IC:\PROGRA~1\MICROS~1.0\VC\include
> -IC:\PROGRA~1\MICR
> OS~1.0SD\include -IC:\PROGRA~1\MICROS~1.0SD\include
> -IC:\ooo\DEV300_m81\solver\3
> 00\wntmsci12.pro\inc\offuh -I. -I..\..\res -I. -DWNT -DNT351 -DMSC
> -DM1500 -DSOL
> AR_JAVA -DFULL_DESK -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0
> -DUPDVER="300m81(Buil
> d:9509)" ..\..\wntmsci12.pro\misc\misc\mediatyp.src C:\Documents and
> Settings\ut
> ente1\AAC.tmp
> Preprocessor startline:
> C:/ooo/DEV300_m81/solver/300/wntmsci12.pro/bin/rscpp @C
> :\Documents and Settings\utente1\AAD.tmp
> cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
> Error starting preprocessor
> dmake:  Error code 1, while making '../../wntmsci12.pro/srs/misc.srs'

not sure what the problem is here.
maybe in the call to rscpp the  @C:\Documents and Settings\utente1\AAD.tmp
needs to have "s around it?
if that helps then "rsc" is too dumb to put quotes in and should be fixed.

or maybe it's a consequence of "transex3" failing before?

hmm, why is this temp file not created in $TMPDIR?
try setting "export TMP=$TMPDIR", if that helps then the "rsc" is too dumb
to understand $TMPDIR and should be fixed.

> Davide

--
If God had meant for us to be naked, we would have been born that way.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Error on svl modules

Davide Dozza
Michael Stahl ha scritto:

[...]

>> cd tools && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver
>> cd transex && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver

transex dir doesn't exist but exists transex3.

Inside transex3 I can find only a directory named java.

utente1@OOO-NE /cygdrive/c/DEV300_82/transex3
$ ls -la
total 0
drwxr-xr-x+ 1 utente1 Nessuno 0 2010-06-17 17:57 .
drwxr-xr-x+ 1 utente1 Nessuno 0 2010-06-18 07:38 ..
drwxr-xr-x+ 1 utente1 Nessuno 0 2010-06-17 17:57 java

therefore I cannot build transex3 !!!!

This happens both for m81 and m82 tags.

I'm trying the others suggestions.

Davide



signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Michael Stahl-3
On 18/06/2010 10:49, Davide Dozza wrote:

> Michael Stahl ha scritto:
>
> [...]
>
>>> cd tools && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver
>>> cd transex && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver
>
> transex dir doesn't exist but exists transex3.
>
> Inside transex3 I can find only a directory named java.

sorry, i assumed that if there's a "transex3" module, then that's where a
"transex3" program would be build.  actually it seems to be built in
module "l10ntools".  how intuitive.

--
"Success is the ability to go from one failure to another
 with no loss of enthusiasm." -- Sir Winston Churchill


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Error on svl modules

Davide Dozza
Michael Stahl ha scritto:

> On 18/06/2010 10:49, Davide Dozza wrote:
>> Michael Stahl ha scritto:
>>
>> [...]
>>
>>>> cd tools && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver
>>>> cd transex && rm -r wntmsci12* && build debug=t -P4 && DISABLE_STRIP=t deliver
>> transex dir doesn't exist but exists transex3.
>>
>> Inside transex3 I can find only a directory named java.
>
> sorry, i assumed that if there's a "transex3" module, then that's where a
> "transex3" program would be build.  actually it seems to be built in
> module "l10ntools".  how intuitive.
>
I did it.

The problem happens on tstring.cxx

xub_StrLen ImplStringLen( const sal_Char* pStr )
{
        const sal_Char* pTempStr = pStr;
        while( *pTempStr )
                ++pTempStr;
        return (xub_StrLen)(pTempStr-pStr);
}

*pTempStr is a null pointer.

Davide


signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Michael Stahl-3
On 18/06/2010 11:50, Davide Dozza wrote:
> I did it.

ok,

> The problem happens on tstring.cxx
>
> xub_StrLen ImplStringLen( const sal_Char* pStr )
> {
> const sal_Char* pTempStr = pStr;
> while( *pTempStr )
> ++pTempStr;
> return (xub_StrLen)(pTempStr-pStr);
> }
>
> *pTempStr is a null pointer.
>
> Davide

well, yes, that's where it crashes.
but the problem is that somebody is calling the Len() function on a null
pointer.
you need to post the stack backtrace to find out where the cause of the
problem is.
to get the backtrace you need to attach the debugger somehow.
(i don't usually work on windows, so i can't remember how that is done...)

--
"Trying to make bits uncopyable is like trying to make water not wet.
 The sooner people accept this, and build business models that take
 this into account, the sooner people will start making money again."
 -- Bruce Schneier


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Error on svl modules

Davide Dozza
Michael Stahl ha scritto:

> On 18/06/2010 11:50, Davide Dozza wrote:
>> I did it.
>
> ok,
>
>> The problem happens on tstring.cxx
>>
>> xub_StrLen ImplStringLen( const sal_Char* pStr )
>> {
>> const sal_Char* pTempStr = pStr;
>> while( *pTempStr )
>> ++pTempStr;
>> return (xub_StrLen)(pTempStr-pStr);
>> }
>>
>> *pTempStr is a null pointer.
>>
>> Davide
>
> well, yes, that's where it crashes.
> but the problem is that somebody is calling the Len() function on a null
> pointer.
> you need to post the stack backtrace to find out where the cause of the
> problem is.
> to get the backtrace you need to attach the debugger somehow.
> (i don't usually work on windows, so i can't remember how that is done...)
>
I'm not an expert too but is it the call stack?
It's enough if I just cut and paste info in it?

Davide


signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Michael Stahl-3
On 18/06/2010 12:08, Davide Dozza wrote:

> Michael Stahl ha scritto:
>> On 18/06/2010 11:50, Davide Dozza wrote:
>>> I did it.
>> ok,
>>
>>> The problem happens on tstring.cxx
>>>
>>> xub_StrLen ImplStringLen( const sal_Char* pStr )
>>> {
>>> const sal_Char* pTempStr = pStr;
>>> while( *pTempStr )
>>> ++pTempStr;
>>> return (xub_StrLen)(pTempStr-pStr);
>>> }
>>>
>>> *pTempStr is a null pointer.
>>>
>>> Davide
>> well, yes, that's where it crashes.
>> but the problem is that somebody is calling the Len() function on a null
>> pointer.
>> you need to post the stack backtrace to find out where the cause of the
>> problem is.
>> to get the backtrace you need to attach the debugger somehow.
>> (i don't usually work on windows, so i can't remember how that is done...)
>>
>
> I'm not an expert too but is it the call stack?
> It's enough if I just cut and paste info in it?
>
> Davide

did you attach something to your mail?
because i'm wondering what "it" is, and the most likely explanation is
that "it" is an attachment that the silly mailing list software has
removed from your mail.

please paste "it" into your mail instead :)

--
Why does New Jersey have more toxic waste dumps and California
have more lawyers? - New Jersey had first choice.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Error on svl modules

Davide Dozza
Michael Stahl ha scritto:

> On 18/06/2010 12:08, Davide Dozza wrote:
>> Michael Stahl ha scritto:
>>> On 18/06/2010 11:50, Davide Dozza wrote:
>>>> I did it.
>>> ok,
>>>
>>>> The problem happens on tstring.cxx
>>>>
>>>> xub_StrLen ImplStringLen( const sal_Char* pStr )
>>>> {
>>>> const sal_Char* pTempStr = pStr;
>>>> while( *pTempStr )
>>>> ++pTempStr;
>>>> return (xub_StrLen)(pTempStr-pStr);
>>>> }
>>>>
>>>> *pTempStr is a null pointer.
>>>>
>>>> Davide
>>> well, yes, that's where it crashes.
>>> but the problem is that somebody is calling the Len() function on a null
>>> pointer.
>>> you need to post the stack backtrace to find out where the cause of the
>>> problem is.
>>> to get the backtrace you need to attach the debugger somehow.
>>> (i don't usually work on windows, so i can't remember how that is done...)
>>>
>> I'm not an expert too but is it the call stack?
>> It's enough if I just cut and paste info in it?
>>
>> Davide
>
> did you attach something to your mail?
> because i'm wondering what "it" is, and the most likely explanation is
> that "it" is an attachment that the silly mailing list software has
> removed from your mail.
>
> please paste "it" into your mail instead :)
>
This is the call stack entries.

tlmi.dll!ImplStringLen(const char * pStr=0x00000000)  Line 81 + 0x3
bytes C++

tlmi.dll!String::String(const char * pByteStr=0x00000000, unsigned short
eTextEncoding=11, unsigned long nCvtFlags=819)  Line 95 + 0x12 bytes C++

  transex3.exe!Export::GetTempFile()  Line 707 + 0x1e bytes C++

  transex3.exe!Export::GetNativeFile(ByteString sSource={...})  Line 623
+ 0x9 bytes C++

        transex3.exe!GetNextFile()  Line 251 + 0x33 bytes C++

  transex3.exe!main(int argc=11, char * * argv=0x00964528)  Line 289 +
0x5 bytes C

  transex3.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes C
  kernel32.dll!7c817077()
  [Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]


Therefore by double clicking starting on top of call stack I have:

tstring.cxx
 - pTempStr bad pointer

structvt.cxx
- rtl_string2UString( (rtl_uString **)(&mpData),
                pByteStr, ImplStringLen( pByteStr ),
                eTextEncoding, nCvtFlags );

export2.cxx
- String sTempDir( Export::GetEnv( "TEMP" ), RTL_TEXTENCODING_ASCII_US );

export2.cxx
- DirEntry aTemp( GetTempFile());

export.cxx

srclex.l
- if ( !pFile )

I don't know if it's clear enough.

Anyway what I find strange it such line code in export2.cxx:
String sTempDir( Export::GetEnv( "TEMP" ), RTL_TEXTENCODING_ASCII_US

The TEMP variable is involved.

I'll try to change it to C:/Temp instead of Documents and
Settings/utente1/Temp

Davide









signature.asc (267 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Error on svl modules

Michael Stahl-3
On 18/06/2010 14:26, Davide Dozza wrote:

> This is the call stack entries.
>
> tlmi.dll!ImplStringLen(const char * pStr=0x00000000)  Line 81 + 0x3
> bytes C++
>
> tlmi.dll!String::String(const char * pByteStr=0x00000000, unsigned short
> eTextEncoding=11, unsigned long nCvtFlags=819)  Line 95 + 0x12 bytes C++
>
>   transex3.exe!Export::GetTempFile()  Line 707 + 0x1e bytes C++
>
>   transex3.exe!Export::GetNativeFile(ByteString sSource={...})  Line 623
> + 0x9 bytes C++
>
> transex3.exe!GetNextFile()  Line 251 + 0x33 bytes C++
>
>   transex3.exe!main(int argc=11, char * * argv=0x00964528)  Line 289 +
> 0x5 bytes C
>
>   transex3.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes C
>   kernel32.dll!7c817077()
>   [Frames below may be incorrect and/or missing, no symbols loaded for
> kernel32.dll]
>
>
> Therefore by double clicking starting on top of call stack I have:
>
> tstring.cxx
>  - pTempStr bad pointer
>
> structvt.cxx
> - rtl_string2UString( (rtl_uString **)(&mpData),
> pByteStr, ImplStringLen( pByteStr ),
> eTextEncoding, nCvtFlags );
>
> export2.cxx
> - String sTempDir( Export::GetEnv( "TEMP" ), RTL_TEXTENCODING_ASCII_US );

ok, that's the problem.
apparently you don't have the $TEMP variable defined, so GetEnv returns a
null pointer.
but transex3 really shouldn't crash here, so i've filed:
http://qa.openoffice.org/issues/show_bug.cgi?id=112512

you can try to apply the patch i've attached in the issue and rebuild
l10ntools.
alternatively setting TEMP should also work.

> export2.cxx
> - DirEntry aTemp( GetTempFile());
>
> export.cxx
>
> srclex.l
> - if ( !pFile )
>
> I don't know if it's clear enough.
>
> Anyway what I find strange it such line code in export2.cxx:
> String sTempDir( Export::GetEnv( "TEMP" ), RTL_TEXTENCODING_ASCII_US
>
> The TEMP variable is involved.
>
> I'll try to change it to C:/Temp instead of Documents and
> Settings/utente1/Temp
>
> Davide

--
"We also go to all kinds of interesting lengths to avoid problems with
 viruses and worms.  For example, we have a hack in our flavor of Wine,
 in the CreateProcess call (the code to start an executable) that
 basically checks to see if the parent process is outlook.exe, and if
 it is, we crash and burn, preventing many of the worms and such from
 running." -- Jeremy White


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]