Education Project/Effort/Various adaptations on Sugar/Work In Progress

From Apache OpenOffice Wiki
Jump to: navigation, search

Building OOo

Building OOo4Kids on Sugar

Distribution: Sugar on a Stick "Strawberry"

Required packages: yum install gcc gcc-c++ bison flex patch freetype-devel libX11-devel libXaw-devel libXrandr-devel perl-Archive-Zip make pam-devel gperf GConf2-devel python-devel curl-devel

gtk is also required, unfortunately Strawberry crashed each time I tried to install the package, therefore this preliminary build will be done using --disable-gtk

Current state: crash at module basebmp. Twarz 12:21, 17 August 2009 (UTC)

Building OOo4Kids on Ubuntu9.04

I tried building OOo4Kids on a more recent computer than the first time. Compiling OOo was okay, but when I apply the patch for OOo4Kids, run the configure / bootstrap / everything, the compilation will always send this error line: "dmake: /home/twarz/OOo/OpenOfficeSrc/DEV300_m52/solenv/inc/unxlngx6.mk: line 142: Error: -- Expecting macro or rule defn, found neither"

I'm still trying to fix this issue, but I'm a bit at a loss of words: I even tried to copy/paste the solenv directory from the working OOo4Kids build and it still doesn't work.

Edit: in the solenv/inc/unxlngx6.mk, starting from line 139: comment the ".IF... .ENDIF", and add the modules that were in the ".ELSE" just before the comments. Compilation for OOo4Kids then goes normaly for some time before encountering some new errors.

Edit: build is now fonctionnal. Here is the list of what has been modified:

-File framework/source/services/backingwindow.cxx wasn't compiling because of undeclared variables. Said variables were located in conditions depending specifically on a build of OOo4Kids or OOo. Solution: commenting the problematic lines. WARNING: to be used only for the compilation of OOo4Kids. Things might go wrong if you try to build OOo with those comments...

Precise location of the comments: line 305, 309, 459, 462.

-File svx/source/cui/treeopt.cxx : same problem as above.

Precise location of the comments : line 2166.

-File scp2/source/calc/calc_module.scp :

Starting from line 95 should be:

 #ifndef OOo4Kids
 gid_File_Res_Analysis,
 #endif

Line 44:

 .IF "$(OOo4Kids)"=="YES"
 SCPDEFS+=-DOOo4Kids
 .ENDIF


-File scp2/source/math/makefile.mk

Just add:

 .IF "$(OOo4Kids)"=="YES"
 SCPDEFS+=-DOOo4Kids
 .ENDIF

Build at least fonctionnal. :)

Starting from DEV300_m54, all previous modifications are not needed anymore.

Twarz 12:36, 17 August 2009 (UTC)

Building on Windows Vista

OOo4Kids...

Building OOo4Kids on Windows Vista is not that hard, but there is still some trouble to go through this process. Actually, until using CPAN on Cygwin. Until then, this is going smoothly but i had some trouble installing Archive::Zip and URI modules, after many unsucsessful try, it worked suddenly: i just made a reboot. Then applying the patch, the configure and all the other things went smoothly till the build. I tried on different version of OOo4Kids and even on OOo and there is still the same building problem that i don't know how to go through:

echos: Command not found. d:/OOo4Kids/DEV300_m52/solver/300/wntnsci12.pro/bin: Permission denied. dmake: Error code 1, while making '../wntmsci12.pro/obj/wrap_hidclex.obj' dmake: '../wntmsci12.pro/obj/wrap_hidclex.obj' removed. runnid processes: 0

3 module(s): hsqldb stax soltools need(s) to be rebuilt

Reasons:

ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/stax ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/soltools/support ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/soltools/HIDCompiler ERROR: error 65280 occured while making /cygdrive/d/OOo4Kids/DEV300_m52/hsqld

I'm still trying to go through this.

"""""""""""""""""

I think I already read something about that. Are there space in the paths, or did you really keep the filetype set to “Unix/binary” ? (that's a cygwin option)

IMHO, the answer is given at Building on Windows

Ericb 13:28, 2 August 2009 (UTC)


DEV300_m54: built correctly, still had to change a few things to complete the build (see Building OOo4Kids at home, I encountered the same problems in solenv/inc/unxlngx6.mk, svx/source/cui/treeopt.cxx and framework/source/services/backingwindow.cxx). The binary in itself works fine and I've been able to reproduce some crashes I found on the m52 versions. Valgrind logs will follow during this week.

Twarz 18:13, 5 August 2009 (UTC)

...with symbols

Using: DEV300_m55 version

In a first time, i have built this version from scrath following this wikipage: http://wiki.ooo4kids.org/index.php/EnvironmentSetup/Windows. This went smoothly, without any problem. When the build was complete, I went in the directory instsetoo_native/wntmsci12.pro/OOo4Kids/msi/install/fr and installed it via explorer. I made some tests and then wanted to try it with Visual Studio Debugger, and here are the problems.

Once at this point, i tried to use it without using the symbols, but that was a bad idea since VS didn't have the source of OOo4Kids so debuggging with it was useless. I imported the sources without more results, then Eric and Twarz told me about building with the symbols. When doing this, i went into a problem with the sw/source/core/doc/dbgoutsw.cxx line 996 as dbg_out is defined at some other place (same error once this one is fixed line 1024) and i commented it, but that might not be a solution as there is problems with symbols after that.

And so there are problems with the build with symbols as in sw/wntmsci12.pro/lib there is nothing as big as 700 or 800MO but 2.5MO for the biggest one.

belabb_a 12:01, 26 August 2009 (UTC)

Debugging

Writer crash: paragraph limit

How to reproduce

  • Open a Writer Document
  • Copy a full page of text, no space, no new line
  • Paste, paste, paste... Around page 14-15, the paste will brutally stop, unfinished.
  • Erase the last character, write a new one.

=> Crash

Where is the problem

file: sw/source/core/text/txtfrm.cxx

method: xub_StrLen SwTxtFrm::FindBrk(const XubString &, const xub_StrLen, const xub_StrLen) const

line: 665-666 :

       while( nFound <= nEndLine && ' ' != rTxt.GetChar( nFound ) )
               ++nFound;

What is exactly happening

This file contain two very similar "while"s :

       while( nFound <= nEndLine && ' ' == rTxt.GetChar( nFound ) )
                ++nFound;        
       while( nFound <= nEndLine && ' ' != rTxt.GetChar( nFound ) )
               ++nFound;

In every case, the first one goes on correctly. The second one, though, is the compromised one.When the crash is happening, nEndLine value is set to 65535. The program skips the first while and directly start processing the second one. nFound initial value is set to 65463. The while goes on until nFound reaches 65534... And suddenly see it's value reinitialised to 0. The problem seems to be located in the rTxt.GetChar method. When nFound reaches 65534 or 65535, this function seems to put back it's value to 0, therefore blocking the program in this "while" (0->65535->0->65535->...)

The function that needs attention is XubString::GetChar . If, of course, I didn't do anything wrong, which is still highly possible.

Twarz 11:22, 10 August 2009 (UTC)

How to solve the problem

This problem has been half solved. The crash indeed was caused by nFound who switched back to 0 once he reached 65535. A problem of type. Therefore, here is my proposition to start fixing the issue. Here is what the compromised function should look like:

 xub_StrLen SwTxtFrm::FindBrk( const XubString &rTxt,
                                                   const xub_StrLen nStart, const xub_StrLen nEnd ) const
 {
         unsigned int nFound1 = nStart;
         const unsigned int nEndLine = Min( nEnd, rTxt.Len() );
 
 	   while( nFound1 <= nEndLine && ' ' == rTxt.GetChar( nFound1 ) )
 		 ++nFound1;
 
 	   unsigned long int nFound2 = nFound1;
 
 	   while( nFound2 <= nEndLine && ' ' != rTxt.GetChar( nFound2 ) )
 		 ++nFound2;
 
	   return (xub_StrLen)nFound2;
 }


This does fix the crash: an unsigned int won't reset reaching 65535. But there is another problem: in the very same conditions where the crash would have occurred and these modifications have been added, the user is unable to write anything anymore. He is stuck at the point when the paste stopped. This problem seems quite unrelated, though, more researches will be needed to find the why of this problem. Well, It's half-solved, so it's still a little progress.

Twarz 15:15, 10 August 2009 (UTC)

Final patch on which Ericb agreed in order to correct the above crash:

 Index: sw/source/core/text/txtfrm.cxx                                                   
 ===================================================================
 --- sw/source/core/text/txtfrm.cxx      (revision 274676)                               
 +++ sw/source/core/text/txtfrm.cxx      (working copy)                                  
 @@ -651,8 +651,8 @@
  xub_StrLen SwTxtFrm::FindBrk( const XubString &rTxt,                                   
                                                   const xub_StrLen nStart, const xub_StrLen nEnd ) const                                                                       
  {                                                                                      
 -       xub_StrLen nFound = nStart;                                                     
 -       const xub_StrLen nEndLine = Min( nEnd, rTxt.Len() );                            
 +       unsigned long int nFound = nStart;                                                   
 +       const unsigned long int nEndLine = Min( nEnd, rTxt.Len() );                          
                                                                                         
         // Wir ueberlesen erst alle Blanks am Anfang der Zeile (vgl. Bug 2235).         
         while( nFound <= nEndLine && ' ' == rTxt.GetChar( nFound ) )                    
 @@ -665,7 +665,7 @@
         while( nFound <= nEndLine && ' ' != rTxt.GetChar( nFound ) )                    
                 ++nFound;                                                               
                                                                                         
 -       return nFound;                                                                  
 +       return (xub_StrLen)nFound;                                                      
  }                                                                                      
                                                                                         
  /************************************************************************* 

Twarz 20:04, 10 August 2009 (UTC)

The issue + patch have been submitted to IssueZilla on this page.

Impress: CPU overuse 1 (presentation wizard)

How to reproduce

  • Open a new presentation
  • In the wizard, select 'from template', then click next
  • click next
  • click next
  • Fill one of the boxes until it reaches the end (will work better with a large copy/paste: a pop-up window will tell you that you have reached the limit)
  • Click next

=> Huge loading time for the next page of the wizard, then huge loading time when working on the presentation itself, for any action concerning the first page.

It is not a natural bug (the odds of someone filling one of these boxes is actually pretty low), but the waiting time for the next step to be available is quite impressive.

Twarz 14:12, 17 August 2009 (UTC)


Did you search in the recent issues to be sure the issue is not known  ? (and maybe fixed ?)

Ericb 21:46, 17 August 2009 (UTC)


I searched and it seems like the issue has not been presented already. Update: on both OOo and OOo4Kids, once the presentation has started, any action intended on the first slide (containing the "name of the company" if you filled the first dialogue box) will cause huge slowdown and CPU overuse. Everything is fine on the other slides.

Twarz 13:01, 18 August 2009 (UTC)

Where is the problem

What is exactly happening

How to solve the problem

Possible correction to this problem could be to reduce the size of the textbox. It is now set à 65535 characters (beside this point, any copy/paste will be automatically truncated), which is waaaaay too much. No company has a name that long, and this indulge an incoherent behaviour because there is no way 65535 characters are going to fit on one slide.

One of the compromised file is vcl/source/control/edit.cxx, line 845, nMaxLen == 65535. A possible solution would be to reduce this number to a coherent value. It would indirectly fix many issues:

  • no more / less slowdown (and CPU overuse) which was caused by a too great number of characters
  • I would fit on the slide (it's useless to have only a fragment of what you wrote on your slide and the rest in empty space, wihch is currently what's happening)

But this file isn't the only one that has to be changed, indeed this one only take care of truncating any copy / paste that would go above the character limit. In ordder to properly and cleanly fix this issue with this idea, we have to locate every thing relevant and set correct values everywhere (in the case of simple writing and not copying/pasting, for instance).

Twarz 15:57, 18 August 2009 (UTC)

Impress:presentation + effect = boom

How to reproduce

  • Erase your preferences.
  • Create a new presentation. Make sure the preview is enabled. Click next.
  • Select a transition effect between slides, whichever you want.
  • Click create at the end of the preview, but before the background turns gray again (basically, the background must be black and the preview must be over)

=> Crash.

Where is the problem

The problem seems to be located in vcl/source/gdi/bmpfast.cxx, line 105. Tracing results will come soon.

Twarz 15:57, 18 August 2009 (UTC)

What is exactly happening

Two major changes have been added to the sources to start correcting this crash, everyhting using gdb (documentation can be checked here). First patch applied:

 Index: slideshow/source/engine/eventmultiplexer.cxx
 ===================================================================
 --- slideshow/source/engine/eventmultiplexer.cxx	(revision 275030)
 +++ slideshow/source/engine/eventmultiplexer.cxx	(working copy)
 @@ -448,8 +448,9 @@
          for( UnoViewVector::const_iterator aIter( mrViewContainer.begin() ),
                   aEnd( mrViewContainer.end() ); aIter != aEnd; ++aIter ) 
          {
 -            ((*aIter)->getUnoView().get()->*pViewMethod)( mxListener.get() );
 -        }
 +	    if ( (*aIter)->getUnoView().get() )
 +    		((*aIter)->getUnoView().get()->*pViewMethod)( mxListener.get() );
 +	}
      }
  }

Why ? Because in this situation, getUnoView()->get() returned NULL, therefore provoking a Segmentation Fault (typical of situation when trying to retreive a variable from a NULL struct pointer). Verification of it's return value->crash corrected.

Or not. New problem, same situation:

 Index: vcl/source/window/window.cxx
 ===================================================================
 --- vcl/source/window/window.cxx	(revision 275032)
 +++ vcl/source/window/window.cxx	(working copy)
 @@ -6372,7 +6372,7 @@
  {
      DBG_CHKTHIS( Window, ImplDbgCheckWindow );
  
 -    if ( mpWindowImpl->mbVisible == bVisible )
 +    if ( mpWindowImpl && mpWindowImpl->mbVisible == bVisible )
          return;
  
      ImplDelData aDogTag( this );

Same thing as above: NULL pointer, trying to retreive a variable->segfault. Same solution: test if mpWindowImpl exists ( != NULL). If it does, go on normally and check the variable. If not, skip the condition and continue.

Now the presentation is launched correctly, and seems to work fine. Unfortunately, there is another problem, always while following the same how-to-reproduce steps (it works fine in every other case). When trying to quit OOo4Kids, the program receive SIGSEGV, Segmentation fault. Here is the compromised fragment of code:

         ImplListBox::~ImplListBox()
 	  {
 	  	delete mpHScrollBar;
 	  	delete mpVScrollBar;
 	  	delete mpScrollBarBox;
 	  }

The problem lies in the line

 delete mpVScrollBar


No idea how to fix that yet, though...

Twarz 16:21, 19 August 2009 (UTC)

How to solve the problem

At first, we thought that only empty presentations were concerned, therefore we only traced in that case. After some tests, it appears the problem also exists on presentation with an already existing template... but at another place in the source code. We fear that this might repeat and that each case will lead to a different location in the code. It would take much time to correct everything manually, therefore a way to fix everything at once would be to disable the "Create" button during the preview, and to reactivate it when the preview is entirely over. Therefore, any timer problem would be avoided.

Twarz 10:02, 31 August 2009 (UTC)

IRC Meetings

IRC meetings logs take a lot of place, therefore they have been moved to this page which will be updated for every future meeting we will have.

Personal tools