Bug 50883 - Events Tab Macro Selector dialog crashes
Summary: Events Tab Macro Selector dialog crashes
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.4 release
Hardware: x86 (IA32) Windows (All)
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-06-08 08:06 UTC by Richard Rupsis
Modified: 2012-08-13 21:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
backtrace of all threads (15.66 KB, text/plain)
2012-06-25 18:13 UTC, Markus Mohrhard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Rupsis 2012-06-08 08:06:12 UTC
Can't assign macro to push button in Calc. When in Events Tab Macro Selector
dialog crashes. I am using the correct procedure because it works in LibO 3.3.4.1
Windows XP
Comment 1 Julien Nabet 2012-06-08 11:49:20 UTC
On pc Debian x86-64 with 3.5 branch and master branch (future 3.7), both updated today with a brand new LO profile, I tested this :
- Open Calc
- Menu Tools/Customize
- Click Events tab
- Select any event
- Click on Macro button

Perhaps there's a next step but I had no crash.
I certainly missed something, could you give more details ? What type of macros, where's stored the macro ?
Comment 2 Richard Rupsis 2012-06-08 13:54:52 UTC
> calc
> View
> Toolbars
> Form Controls
> Click on "Push Button" icon (Design Mode On)
> Use Mouse to draw a button on the spreadsheet
> Right click on the button
> Click on "Control" to open "Properties" dialog
> Click on "Events" tab
> Click on "Mouse button pressed" this opens the "Assignment" dialog
> When "Macro" clicked crashes

I installed older Libo 3.3.4 and this procedure works fine, but
on Libo 3.5.4.2 and 3.5.3.2 crashes


On Fri, Jun 8, 2012 at 2:49 PM, <bugzilla-daemon@freedesktop.org> wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=50883
>
> Julien Nabet <serval2412@yahoo.fr> changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>             Status|UNCONFIRMED                 |NEEDINFO
>                 CC|                            |serval2412@yahoo.fr
>     Ever Confirmed|0                           |1
>
> --- Comment #1 from Julien Nabet <serval2412@yahoo.fr> 2012-06-08
> 11:49:20 PDT ---
> On pc Debian x86-64 with 3.5 branch and master branch (future 3.7), both
> updated today with a brand new LO profile, I tested this :
> - Open Calc
> - Menu Tools/Customize
> - Click Events tab
> - Select any event
> - Click on Macro button
>
> Perhaps there's a next step but I had no crash.
> I certainly missed something, could you give more details ? What type of
> macros, where's stored the macro ?
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>
Comment 3 Julien Nabet 2012-06-08 14:25:49 UTC
First thank you for your quick and useful feedback ! 

I tried to reproduce within and without gdb session.
Without gdb, I didn't reproduce the problem badfully
Within gdb, I had a segfault, eg here the backtrace :
 Program received signal SIGSEGV, Segmentation fault.
0x00007f65c582b288 in ?? ()
(gdb) bt
#0  0x00007f65c582b288 in ?? ()
#1  0x00007f65c57cbdd0 in ?? ()
#2  0x00007fff00000000 in ?? ()
#3  0x00007fffea607e98 in ?? ()
#4  0x00007fffea607e50 in ?? ()
#5  0x000000000000008b in ?? ()
#6  0x0000000000000000 in ?? ()
(gdb) c
But by going on, the macro dialog appears as if segfault hadn't happen.
I had the same behaviour with 3.5 branch and master.

We need someone (certainly a Windows user) to retrieve a more useful bt.
(If you're interested in this subject, there's a great video here http://www.youtube.com/watch?v=fppBTs215yc)
Comment 4 bfoman (inactive) 2012-06-14 02:06:42 UTC
Checked with:
LO 3.5.4.2 
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Could not reproduce (steps per comment 2).
Comment 5 Rainer Bielefeld Retired 2012-06-14 23:17:31 UTC
NOT reproducible with "LibreOffice 3.5.5.1  German UI/Locale [Build-ID: c9944f7-48b7ff5-0507789-54a4c8a-8b242a8] on German WIN7 Home Premium (64bit) due to Comment 2
Comment 6 Markus Mohrhard 2012-06-25 18:13:30 UTC
@Stephan: A problem with java. See attached my backtrace which shows a lot of java threads. Do you have an idea? In the end LO is killed by an SIGILL created by the Java VM.

I have no idea how to debug this one.
Comment 7 Markus Mohrhard 2012-06-25 18:13:59 UTC
Created attachment 63469 [details]
backtrace of all threads
Comment 8 Stephan Bergmann 2012-07-09 08:38:20 UTC
(In reply to comment #3)
> I tried to reproduce within and without gdb session.
> Without gdb, I didn't reproduce the problem badfully
> Within gdb, I had a segfault, eg here the backtrace :
>  Program received signal SIGSEGV, Segmentation fault.
[...]
> But by going on, the macro dialog appears as if segfault hadn't happen.

SIGSEGV from within JIT'ed JVM code is normal and harmless (JVM signal handler catches it an synthesizes java.lang.NullPointerException from it).

Markus, I assume attachment 63469 [details] also only shows backtraces at the time of such a harmless JVM SIGSEGV?  (That is, you were not able to reproduce the problem either?)
Comment 9 Markus Mohrhard 2012-07-13 04:12:22 UTC
(In reply to comment #8)
> (In reply to comment #3)
> > I tried to reproduce within and without gdb session.
> > Without gdb, I didn't reproduce the problem badfully
> > Within gdb, I had a segfault, eg here the backtrace :
> >  Program received signal SIGSEGV, Segmentation fault.
> [...]
> > But by going on, the macro dialog appears as if segfault hadn't happen.
> 
> SIGSEGV from within JIT'ed JVM code is normal and harmless (JVM signal handler
> catches it an synthesizes java.lang.NullPointerException from it).
> 
> Markus, I assume attachment 63469 [details] also only shows backtraces at the time of
> such a harmless JVM SIGSEGV?  (That is, you were not able to reproduce the
> problem either?)

I'm able to reproduce it. The backtrace is the result of the last SIGSEGV before it crashes with a SIGILL.
Comment 10 Noel Power 2012-08-09 15:26:44 UTC
markus, any update, is this still reproduceable in the latest 3.5/3.6 trees ( at least I can't reproduce it :( )
Comment 11 Markus Mohrhard 2012-08-13 21:06:53 UTC
Currently not but I have only access to my laptop with a minimal build. If I'll get access to my big computer any time soon I will check and if I can reproduce it I will reopen the bug.