Bug 60036 - scalc always crashes at startup with particular user profile
Summary: scalc always crashes at startup with particular user profile
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.4.3 release
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: BSA target:4.3.0 target:4.2.1
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-29 20:21 UTC by tim
Modified: 2014-01-31 01:23 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
These is the old user profile that was causing the problem (620.75 KB, application/x-zip)
2013-01-30 19:04 UTC, tim
Details
This is the new User Profile that works for me (378.05 KB, application/x-zip)
2013-01-30 19:40 UTC, tim
Details
bt on master (8.72 KB, text/plain)
2013-01-30 19:54 UTC, Julien Nabet
Details
gdb session (3.02 KB, text/plain)
2013-01-30 20:27 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2013-01-29 20:21:47 UTC
Problem description: scalc.exe always crashes when every I try to start the programing.

Steps to reproduce:
1. Start libre office
2. select spread sheet icon

Current behavior: always crashes

Expected behavior: do not crash

I started scalc from windbg

Here is what I got:

CommandLine: "C:\Program Files\LibreOffice 3.6\program\scalc.exe"
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is: 
ModLoad: 00400000 00412000   scalc.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 7e410000 7e4a1000   C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f59000   C:\WINDOWS\system32\GDI32.dll
ModLoad: 78520000 785c3000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43\MSVCR90.dll
(130c.1328): Break instruction exception - code 80000003 (first chance)
eax=00251eb4 ebx=7ffd7000 ecx=00000005 
edx=00000020 esi=00251f48 edi=00251eb4
eip=7c90120e esp=0012fb20 ebp=0012fc94 
iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
ntdll!DbgBreakPoint:
7c90120e cc              int     3

              
Operating System: Windows XP
Version: 3.6.4.3 release
Comment 1 Julien Nabet 2013-01-29 20:50:55 UTC
Do you have the crash only with scalc or with other applications too?
Did you install any specific extensions?
Did you install any specific fonts?
What's your Java version?

Did you try to rename your LO directory profile? (see https://wiki.documentfoundation.org/UserProfile)
Comment 2 tim 2013-01-30 16:05:56 UTC
====================================================
Great job the problem is now fixed !!!!!

I did these recommendations: 
https://wiki.documentfoundation.org/UserProfile)

I have been dealing with this problem on multiple versions of libre office.

Note: This machine use to have open office and Microsoft office in the past.
Maybe one of these programs caused the problems with the UserProfile data.

====================================================


>> Do you have the crash only with scalc or with other applications too?
scalc.exe only

>> Did you install any specific extensions?
Yes but I removed previous versions and did a clean reinstall.

>> Did you install any specific fonts?
No

>> What's your Java version?
I think I also removed all versions of java to try and see the affect,
but it did not help.
Comment 3 Julien Nabet 2013-01-30 17:00:26 UTC
Tim: great for you, your problem is solved! :-) However if there's an underlying bug, this one isn't solved.
By any chance, do you still have the buggy LO directory profile? (if yes could you zip it and attach it to the bugtracker)

Put it WFM for the moment since there's no specific fix (in the code).
Comment 4 tim 2013-01-30 19:04:28 UTC
Created attachment 73942 [details]
These is the old user profile that was causing the problem

I have attached a zip file containing the old User Profile that was causing the problem.

Again: thanks for the help!!!!
Comment 5 tim 2013-01-30 19:40:34 UTC
Created attachment 73946 [details]
This is the new User Profile that works for me

I figured that if I give a working profile and a non-working profile (old),
that the developer can let the computer do a difference,
and then the developer can then zero-in on the differences.

Hopefully this will save some time.
Comment 6 Julien Nabet 2013-01-30 19:54:56 UTC
Created attachment 73951 [details]
bt on master

On pc Debian x86-64 with master sources udpated today, I reproduced the crash with "buggy" profile from reporter so I reopen this.
Comment 7 Julien Nabet 2013-01-30 19:56:09 UTC
Cedric/Michael: bt on master with symbols attached (same pb on 3.6 too), one for you?
Comment 8 Michael Stahl (allotropia) 2013-01-30 20:00:23 UTC
crashes in Calc, better add some Calc devs...
Comment 9 Julien Nabet 2013-01-30 20:03:28 UTC
Michael: Oups! You're absolutely right, I don't know why I thought Writer and so put in cc Cédric and you. Sorry for this.

Put it at NEW since bt retrieved.
Comment 10 Julien Nabet 2013-01-30 20:27:10 UTC
Created attachment 73953 [details]
gdb session

I noticed that aLRUList.size() = 8 but in last loop, we got:
795	                    pAllFuncList->InsertEntry(pDesc->getFunctionName()),
(gdb) p pDesc->getFunctionName()
Cannot access memory at address 0x0

(see attachment for more details)
Comment 11 Cédric Bosdonnat 2014-01-20 09:00:28 UTC Comment hidden (noise)
Comment 12 Eike Rathke 2014-01-21 12:00:36 UTC
Is this still a problem? I guess it was solved by some upgrade to 4.x
Comment 13 Commit Notification 2014-01-27 12:09:53 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a94f0f92e8b09f6cd3989b646500ff5814274621

guard against null pointer access on LRU function list, fdo#60036



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2014-01-31 01:23:38 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-4-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6592543a598994e44823b7e1158e34b0c6ec82d3&h=libreoffice-4-2

guard against null pointer access on LRU function list, fdo#60036


It will be available in LibreOffice 4.2.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.