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

From Apache OpenOffice Wiki
Jump to: navigation, search

Work on OOo/OOo4Kids

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)

...with debugging symbols

Using: DEV300_m55 version

In a first time, i have built this version from scrath following this wikipage. 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 (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: timer crash

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)

Problem reported on IssueZilla.

Work on XOs

Quick Introduction

After receiving the XOs, Kidd and myself will be able to engage into the most interesting part of our training period: adapting OOo4Kids on Sugar, and being able to run it on the XO laptops. We will basically proceed as follow: experiment, locate, correct, meaning we will spend a lot of time on merely using OOo4Kids, trying to find bugs and / or feature to optimize, then use the tools at our disposition (gdb, valgrind, callgrind...) to locate them precisely in the code, then with Eric Bachard's and Pierre Pasteau's help do our best to correct and suggest a working patch that will be submitted to the next version of OOo4Kids and maybe even OOo. Our objectives are as follow:

  • submit at least 2 visible performance improvement (one per student, possibly more if time allows it);
  • submit at least 2 UI improvement (just as above, at least one per student);

Any progress made on the XOs or on OOo4Kids itself will be reported on this page, in the corresponding section. Progress worth mentioning on the XO will also be reported on this blog.

Promoting the XO

Receiving the XO will also allow us to assist Eric Bachard during a conference that will take place in october. Many points will be presented during this conference: the Education project, in order to make OOo4Kids more known of the public, our own project of contributing to the source code, and of course a presentation of the XO, their capacities, their goal, and an overall view of the OLPC fundation.

Quick Presentation of the XO

XO's laptops are an initiative of the OLPC (One Laptop Per Children) association. They are low-cost laptops (available for poor children) with low performances using Sugar (a Linux using neither KDE nor Gnome but a new type of interface). There are three type of XO, the XO-1, the XO-1.5 and the XO-2.

The XO-1 is using an AMD Geode LX-700@0.8W processor with a CPU frequency of 433MHz, and an AMD CS5536 South Bridge chipset. It has 256Mo of RAM and 1GO of flash memory. The XO-1.5 is a XO-1 update as the processor is now a VIA C7-M with a CPU frequency of 1GHz and 4GO of flash memory (and some other things).

The XO-1 laptop with the Sugar desktop




The XO-2 really changes the laptop's shape, as there is no more keyboard but a double touch-sreen that will allow the development of whole new activities.

The XO-2, yet to come








Direct Work on XOs

Improving OOo4Kids' Performances

Memory

XOs are laptops with a really low amount of RAM. Therefore, one of the major objectives will be to make sure that the memory leaks are close to none. If not, OOo4Kids might be unusable on the laptops. We will probably be using mainly Valgrind in order to locate and correct the biggest leaks. Many tests will be carried out:

  • letting the program run for a long time, with a huge amount of information provided;
  • filling an Impress wizard with a lot of information, then cancel (this test has been proved positive on the current version of OOo4Kids and will require special attention);
  • deleting figures, text, drawings... during a session, and make sure the memory that was used is correctly freed;
  • Check previews and slideshows (Impress' wizard);
  • checking the limit of the documents and try to expand it by suppressing unused memory;
  • simply checking a normal, basic usage of the different applications
  • secondary: location and termination of eventuals invalid frees/delete

The idea is to see how much memory OOo4Kids is using at the very beginning, when displaying the Start Center, when the user hasn't done anything. Then, carry on the tests, cancel everything, and come back to the Start Center. If the amount of memory used by OOo4Kids is different at that time, then there is a memory leak.

Here is how we will proceed to locate the memory leaks once they have been recognized as such (this is also a more precise way to see if there is indeed a memory leak). We will be using Valgrind (the following values are based on milestone 56, and will be updated as soon as the next milestone will be available).

First, launch OOo4Kids with Valgrind, reach the Start Center, and quit immediatly. Here is the result:

 ==578== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 1418 from 3)
 ==578== malloc/free: in use at exit: 2,240,486 bytes in 10,319 blocks.
 ==578== malloc/free: 41,644 allocs, 31,326 frees, 10,481,760 bytes allocated.
 ==578== For counts of detected errors, rerun with: -v
 ==578== Use --track-origins=yes to see where uninitialised values come from
 ==578== searching for pointers to 10,319 not-freed blocks.
 ==578== checked 22,363,496 bytes.
 ==578== 
 ==578== LEAK SUMMARY:
 ==578==    definitely lost: 13,796 bytes in 327 blocks.
 ==578==      possibly lost: 122,753 bytes in 89 blocks.
 ==578==    still reachable: 2,103,937 bytes in 9,903 blocks.
 ==578==         suppressed: 0 bytes in 0 blocks.

As we can see, there are already some unfreed allocations, but we will overlook them for now. We can now start carrying on the tests, using these values as base value. The idea is that there should always be the same difference of allocs-free - this would mean the action we just done was entirely and correctly freed, meaning the remaining "leaks" are only part of the base value. If the difference is greater, it means the test is positive, and all the memory we just used hasn't been correctly freed. It can be dangerous: if we use OOo4Kids for too long, the used memory will become greater and greater, and cause a crash. Let's try to merely open a Writer document, come back to the Start Center, and quit OOo4Kids. Here is the Valgrind log:

 ==32656== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 2299 from 4)
 ==32656== malloc/free: in use at exit: 2,374,725 bytes in 10,830 blocks.
 ==32656== malloc/free: 64,424 allocs, 53,595 frees, 23,395,607 bytes allocated.
 ==32656== For counts of detected errors, rerun with: -v
 ==32656== Use --track-origins=yes to see where uninitialised values come from
 ==32656== searching for pointers to 10,830 not-freed blocks.
 ==32656== checked 29,136,480 bytes.
 ==32656== 
 ==32656== LEAK SUMMARY:  
 ==32656==    definitely lost: 13,796 bytes in 327 blocks.
 ==32656==      possibly lost: 136,449 bytes in 97 blocks.
 ==32656==    still reachable: 2,224,480 bytes in 10,406 blocks.
 ==32656==         suppressed: 0 bytes in 0 blocks.

Base value: 41644-31326 = 10318

New value: 64424-53595 = 10829

There IS a memory leak. The check the gravity of the leak, we just have to take a look at the "Leak Summary".

Base Value: 13 796 + 122 753 + 2 103 937 = 2 240 448 bytes.

New Value: 13 796 + 136 449 + 2 224 480 = 2 374 725 bytes.

Meaning, there is a leak of 134 277 bytes. It's not too much, this leak is not an urgent matter, but it still represent a minor risk.

This is basically how to proceed with finding a memory leak in the program. To locate it it the code, we will have to use some options of Valgrind and add the debugging symbols to the libraries concerned in the leak.

CPU

Just as for the memory, the XOs laptops have limited ressources in term of CPU. This will be our second important objective: globally optimize OOo4Kids and get rid of any situation that could lead to a 100% use of the CPU.As for the memory leaks, many tests will be made:

  • opening a high number of documents at once, filled with informations;
  • letting the program run alone during different phases of it's execution;
  • fill the dialogue boxes in the wizards (positive on the current version in the Impress wizard) and try to fix the huge slowdown that might result of it;
  • give a special attention to the Impress application which seems to be prone to crashing and is globally under-optimized;

Controlling the CPU usage will be done with two tools on the XO: the shell command "top", that shows a high amount of information about every process being run (including, of course, the % of CPU the process uses), and gdb. How ? Pretty simple. First, run OOo4Kids normally, and find some conditions that will lead to a 100% CPU usage. Then, using gdb, repeat the same condition and stop the program at the right time. This will give us a first indication of where the problem is inside the code. At this point, we will have to read the code and understand what is going on, understand what the code does, and try to find a way to make it do it faster.

Improving OOo4Kids' UI

As precised in the introduction, one of the goal of this training period is to make us develop improvements and new elements in the UI, or improving existing elements.








One page of the Impress Wizard

One of the most likely addition that will be made is a new wizard for the Writer application which for now have none. Based on the Impress wizard, it will suggest at most three pages for the user to personify the document he is about to create. It will therefore be slightly simplified compared to the Impress wizard. It will be created using the same portion of code, for the greatest part located in the file sd/source/ui/dlg/dlgass.cxx





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.

Documentation

First bits of documentation are available here. Few examples until we start for good and documentation will be migrated here.

Planning

Current Work

Here are the results of the day, yet to be classified. Just here to stock informations until we find the time to properly classify them.

Personal tools