|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | defensive coding for mapmode ... | ||
|---|---|---|---|
| Product: | gsl | Reporter: | mmeeks <mmeeks> |
| Component: | code | Assignee: | stephan_schaefer |
| Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | issues |
| Version: | OOo 1.1 RC4 | ||
| Target Milestone: | OOo 2.0 | ||
| Hardware: | PC | ||
| OS: | Linux, all | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
cp->ssa: I would like to see the ressource fixed befor making the defect invisible. please double check with pl and/or nf. Checking for out of bounds cannot be wrong. Michael, if you can still reproduce the problem, it would be nice if you could find out what resource is broken. Thanks. The problem - _I think_ was caused by mis-matched resources across two different builds, where (presumably) something got re-layed out in the resource compilation (or something). At least - I can't reproduce it with a slightly sane setup, only with some hacked-up cross-version, partially built setup ;-) However the defensive pre-condition is obviously correct, and helped at the time so ... ;-) Patch applied. ...and verified. closing |
Just got a _really_ odd numerical instability in this path: #0 0x40a27935 in Fraction::Fraction(long, long) () from ./libtl645li.so #1 0x401c0f1f in ImplMakeFraction (nN1=1, nN2=1, nD1=1, nD2=0) at /opt/OpenOffice/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/outmap.cxx:159 #2 0x401c19b8 in ImplCalcMapResolution (rMapMode=@0xbfffc480, nDPIX=96, nDPIY=96, rMapRes=@0x486d6090) at /opt/OpenOffice/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/outmap.cxx:390 #3 0x401c77a9 in Window::ImplLogicUnitToPixelY(long, MapUnit) (this=0x4a100d68, nY=68, eUnit=336) at /opt/OpenOffice/openoffice/build/OOO_1_1_RC4/vcl/source/gdi/outmap.cxx:2164 #4 0x402598e5 in DockingWindow::ImplLoadRes(ResId const&) () from ./libvcl645li.so #5 0x40259db0 in DockingWindow::DockingWindow(Window*, ResId const&) () from ./libvcl645li.so It turns out there must be some resource incompatibility somewhere between RC3 and RC4 - either way, I get a mapmode unit enum value of 366 which causes this (via. an invalid ScaleX/Y fraction etc.) This patch at least makes OO.o run for me, and is clearly correct: --- vcl/source/gdi/mapmod.cxx 18 Sep 2000 17:05:38 -0000 1.1.1.1 +++ vcl/source/gdi/mapmod.cxx 12 Sep 2003 16:51:13 -0000 @@ -144,6 +144,12 @@ static ImplMapMode* ImplGetStaticMapMode static long aStaticImplMapModeAry[(MAP_LASTENUMDUMMY)*sizeof(ImplMapMode)/sizeof(long)]; #endif + if( eUnit >= MAP_LASTENUMDUMMY ) + { + DBG_ASSERTWARNING( bRelMap, "Completely bogus map unit" ); + return ((ImplMapMode*)aStaticImplMapModeAry); + } + ImplMapMode* pImplMapMode = ((ImplMapMode*)aStaticImplMapModeAry)+eUnit; if ( !pImplMapMode->mbSimple ) { It also interests me that the array of long's isn't initialized to '0' - perhaps C++ garuentees that sort of thing; it'd be easy to add a = { 0 } ; anyway though for ignorant people like me :-)