Bug 99272 - CRASH - Clicking on a field name in step 2 of "Table Creation" wizard crashes Base
Summary: CRASH - Clicking on a field name in step 2 of "Table Creation" wizard crashes...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.2.0 target:5.1.4
Keywords: bibisectRequest, haveBacktrace
: 92580 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-04-13 14:02 UTC by Muhammet Kara
Modified: 2016-10-25 19:01 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
bt with debug symbols (14.40 KB, text/plain)
2016-04-13 20:45 UTC, Julien Nabet
Details
Valgrind trace (but without crash) (321.30 KB, application/gzip)
2016-04-15 15:53 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Muhammet Kara 2016-04-13 14:02:57 UTC
To reproduce on vanilla LO:

1- Launch Base (./instdir/program/sbase) (Database Wizard opens)
2- Go through the Database Wizard to create a new database: Push these buttons in order: Next -> Finish -> Save
3- Wait for Base to save and open the new database.
4- Click "Tables" in the "Database" pane on the left.
5- Click "Use Wizard to Create Table..." in the "Tasks" pane on the top.
6- Wait for the "Table Wizard" dialog to open
7- Click ">>" button to move all available fields to the Selected fields list.
8- Click "Next >" to go to the "Set field types and formats" step
9- Right or left click on the name of any field in the "Selected fields" list.


Observed result:
Base crashes.

Expected result:
The clicked field name is selected.
Comment 1 raal 2016-04-13 15:37:26 UTC
I can not confirm with Version: 5.2.0.0.alpha0+
Build ID: 0f27cc992a99568e46ffe807ef9dbb5ba0bc601f
CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-04-12_23:40:16

If possible, please follow the instructions provided at this link < https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux >. and submit a backtrace. That way a developer can look into the underlying reason of the crash.
Comment 2 Julien Nabet 2016-04-13 20:45:53 UTC
Created attachment 124312 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.

I attached a bt with symbols.
Comment 3 Julien Nabet 2016-04-13 20:47:24 UTC
I don't reproduce this on LO Debian package 5.1.2.0
=> regression
Comment 4 Lionel Elie Mamane 2016-04-14 11:53:09 UTC
(In reply to Julien Nabet from comment #3)
> I don't reproduce this on LO Debian package 5.1.2.0
> => regression

Hmm... Not necessarily. This looks like a debug-only assert. Since the Debian package is not built with debug enabled, this does not show a regression.
Comment 5 Lionel Elie Mamane 2016-04-14 12:23:11 UTC
I'm scratching my head on this one, but I don't catch what's wrong... free() is called incorrectly, but I don't see why. The array is created with new[], and deleted with delete[], so it should be OK.
Comment 6 Lionel Elie Mamane 2016-04-14 12:45:45 UTC
I get the impression that somehow pOldValues[0].pData and the actual storage of the property point towards the same storage, but don't correctly update reference counts, so that the first one destroyed frees the storage, and when the other one is destroyed it is a double free()
Comment 7 Stephan Bergmann 2016-04-15 12:58:20 UTC
The backtrace smells like memory corruption happened earlier and only now leads to an assert.  I cannot reproduce any problem here, with neither an ASan/UBSan build nor with Valgrind.  Maybe somebody who can reproduce the problem can try to see if Valgrind turns up anything for them ("VALGRIND=memcheck instdir/program/soffice --base").
Comment 8 Lionel Elie Mamane 2016-04-15 13:34:07 UTC
With valgrind, the wizard does not even open, I get a SIGSEGV when opening the wizard:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000043026808, pid=5357, tid=68207872
#
# JRE version: OpenJDK Runtime Environment (7.0_95) (build 1.7.0_95-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.95-b01 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.6.4
# Distribution: Debian GNU/Linux 8.2 (jessie), package 7u95-2.6.4-1~deb8u1
# Problematic frame:
# J 56 C2 sun.net.www.ParseUtil.encodePath(Ljava/lang/String;Z)Ljava/lang/String; (336 bytes) @ 0x0000000043026808 [0x0000000043026640+0x1c8]
#
# Core dump written. Default location: /home/master/src/libreoffice/workdirs/libreoffice-5-2/core or core.5357
#
# An error report file with more information is saved as:
# XXXXXXX/hs_err_pidXXXXX.log
Comment 9 Julien Nabet 2016-04-15 15:53:38 UTC
Created attachment 124370 [details]
Valgrind trace (but without crash)

With Valgrind, I haven't had a crash but perhaps the retrieved trace might be useful.
As usual, it's quite polluted by Java parts.
Some config info:
openjdk version "1.8.0_77-Debian"
OpenJDK Runtime Environment (build 1.8.0_77-Debian-8u77-b03-3+b1-b1)
OpenJDK 64-Bit Server VM (build 25.77-b1, mixed mode)

valgrind-3.11.0

gcc version 5.3.1 20160323 (Debian 5.3.1-13)
ldd (Debian GLIBC 2.22-5) 2.22
GNU Make 4.1
Comment 10 Stephan Bergmann 2016-04-15 16:12:33 UTC
Yes, the below part is interesting.  I had seen something similar too with my first attempt at Valgrinding this, but then unfortunately updated my JDK (to Fedora's OpenJDK 1.8.0.77-1.b03.fc23) and afterwards could no longer reproduce it.

Julien, what version of Java are you using?


> ==25248== Invalid write of size 2
> ==25248==    at 0x4C2E7A3: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:1018)
> ==25248==    by 0x4658B4F0: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x5F323A87: JNIEnv_::GetShortArrayRegion(_jshortArray*, int, int, short*) (jni.h:1744)
> ==25248==    by 0x5F31D3AE: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:1001)
> ==25248==    by 0x5F31BCA1: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:626)
> ==25248==    by 0x5F3324A2: jni_uno::Bridge::call_uno(jni_uno::JNI_context const&, _uno_Interface*, _typelib_TypeDescription*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter const*, _jobjectArray*) const (jni_java2uno.cxx:225)
> ==25248==    by 0x5F33333C: Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call (jni_java2uno.cxx:523)
> ==25248==    by 0x47701855: ???
> ==25248==    by 0x477096C3: ???
> ==25248==    by 0x474959D1: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749515F: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4748E4E6: ???
> ==25248==    by 0x46575E1A: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x4658F989: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x4659344D: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x5F33890B: JNIEnv_::CallVoidMethodA(_jobject*, _jmethodID*, jvalue const*) (jni.h:1063)
> ==25248==    by 0x5F336743: jni_uno::Bridge::call_java(_jobject*, _typelib_InterfaceTypeDescription*, int, int, _typelib_TypeDescriptionReference*, _typelib_MethodParameter*, int, void*, void**, _uno_Any**) const (jni_uno2java.cxx:248)
> ==25248==    by 0x5F3381C7: UNO_proxy_dispatch (jni_uno2java.cxx:765)
> ==25248==    by 0x2755E04A: cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) (cpp2uno.cxx:186)
> ==25248==    by 0x2755EAC5: cpp_vtable_call (cpp2uno.cxx:377)
> ==25248==    by 0x27575935: privateSnippetExecutor (in /home/julien/lo/libreoffice/instdir/program/libgcc3_uno.so)
> ==25248==    by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145)
> ==25248==    by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145)
> ==25248==    by 0xC3D3BEA: VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}::operator()() const (vclxwindows.cxx:589)
> ==25248==    by 0xC3F7B1D: std::_Function_handler<void (), VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871)
> ==25248==    by 0xC3CA835: std::function<void ()>::operator()() const (functional:2267)
> ==25248==    by 0xC3BA3CE: VCLXWindowImpl::OnProcessCallbacks(void*) (vclxwindow.cxx:302)
> ==25248==    by 0xC3BA230: VCLXWindowImpl::LinkStubOnProcessCallbacks(void*, void*) (vclxwindow.cxx:274)
> ==25248==    by 0xD92229A: Link<void*, void>::Call(void*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so)
> ==25248==    by 0xD91F133: ImplHandleUserEvent(ImplSVEvent*) (winproc.cxx:1956)
> ==25248==    by 0xD920AF8: ImplWindowFrameProc(vcl::Window*, unsigned short, void const*) (winproc.cxx:2524)
> ==25248==    by 0xDE6881E: SalFrame::CallCallback(unsigned short, void const*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so)
> ==25248==    by 0xDE78C7A: SalGenericDisplay::DispatchInternalEvent() (gendisp.cxx:86)
> ==25248==    by 0x22EEC073: GtkData::userEventFn(void*) (gtk3gtkdata.cxx:809)
> ==25248==    by 0x22EEC100: call_userEventFn (gtk3gtkdata.cxx:819)
> ==25248==    by 0x6DCDFE9: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
> ==25248==    by 0x6DCE38F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
> ==25248==    by 0x6DCE43B: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
> ==25248==    by 0x22EEAF11: GtkData::Yield(bool, bool) (gtk3gtkdata.cxx:467)
> ==25248==    by 0x22EEE1A2: GtkInstance::DoYield(bool, bool, unsigned long) (gtkinst.cxx:407)
> ==25248==    by 0xDD2A794: ImplYield(bool, bool, unsigned long) (svapp.cxx:511)
> ==25248==    by 0xDD265D9: Application::Yield() (svapp.cxx:553)
> ==25248==    by 0xD7CB9EE: Dialog::Execute() (dialog.cxx:887)
> ==25248==    by 0xC3DE598: VCLXDialog::execute() (vclxwindows.cxx:2327)
> ==25248==    by 0xC443843: UnoDialogControl::execute() (dialogcontrol.cxx:617)
> ==25248==  Address 0x2bad09ba is 0 bytes after a block of size 10 alloc'd
> ==25248==    at 0x4C29C0F: malloc (vg_replace_malloc.c:299)
> ==25248==    by 0x4E573F0: rtl_allocateMemory_SYSTEM(unsigned long) (alloc_global.cxx:272)
> ==25248==    by 0x4E57507: rtl_allocateMemory (alloc_global.cxx:305)
> ==25248==    by 0x5F3184C9: jni_uno::rtl_mem::allocate(unsigned long) (jni_base.h:221)
> ==25248==    by 0x5F3251BB: jni_uno::seq_allocate(int, int) (jni_data.cxx:38)
> ==25248==    by 0x5F31D342: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:998)
> ==25248==    by 0x5F31BCA1: jni_uno::Bridge::map_to_uno(jni_uno::JNI_context const&, void*, jvalue, _typelib_TypeDescriptionReference*, jni_uno::JNI_type_info const*, bool, bool, bool) const (jni_data.cxx:626)
> ==25248==    by 0x5F3324A2: jni_uno::Bridge::call_uno(jni_uno::JNI_context const&, _uno_Interface*, _typelib_TypeDescription*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter const*, _jobjectArray*) const (jni_java2uno.cxx:225)
> ==25248==    by 0x5F33333C: Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call (jni_java2uno.cxx:523)
> ==25248==    by 0x47701855: ???
> ==25248==    by 0x477096C3: ???
> ==25248==    by 0x474959D1: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749515F: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4749598C: ???
> ==25248==    by 0x4748E4E6: ???
> ==25248==    by 0x46575E1A: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x4658F989: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x4659344D: ??? (in /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
> ==25248==    by 0x5F33890B: JNIEnv_::CallVoidMethodA(_jobject*, _jmethodID*, jvalue const*) (jni.h:1063)
> ==25248==    by 0x5F336743: jni_uno::Bridge::call_java(_jobject*, _typelib_InterfaceTypeDescription*, int, int, _typelib_TypeDescriptionReference*, _typelib_MethodParameter*, int, void*, void**, _uno_Any**) const (jni_uno2java.cxx:248)
> ==25248==    by 0x5F3381C7: UNO_proxy_dispatch (jni_uno2java.cxx:765)
> ==25248==    by 0x2755E04A: cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) (cpp2uno.cxx:186)
> ==25248==    by 0x2755EAC5: cpp_vtable_call (cpp2uno.cxx:377)
> ==25248==    by 0x27575935: privateSnippetExecutor (in /home/julien/lo/libreoffice/instdir/program/libgcc3_uno.so)
> ==25248==    by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145)
> ==25248==    by 0xC556581: ActionListenerMultiplexer::actionPerformed(com::sun::star::awt::ActionEvent const&) (listenermultiplexer.cxx:145)
> ==25248==    by 0xC3D3BEA: VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}::operator()() const (vclxwindows.cxx:589)
> ==25248==    by 0xC3F7B1D: std::_Function_handler<void (), VCLXButton::ProcessWindowEvent(VclWindowEvent const&)::{lambda()#1}>::_M_invoke(std::_Any_data const&) (functional:1871)
> ==25248==    by 0xC3CA835: std::function<void ()>::operator()() const (functional:2267)
> ==25248==    by 0xC3BA3CE: VCLXWindowImpl::OnProcessCallbacks(void*) (vclxwindow.cxx:302)
> ==25248==    by 0xC3BA230: VCLXWindowImpl::LinkStubOnProcessCallbacks(void*, void*) (vclxwindow.cxx:274)
> ==25248==    by 0xD92229A: Link<void*, void>::Call(void*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so)
> ==25248==    by 0xD91F133: ImplHandleUserEvent(ImplSVEvent*) (winproc.cxx:1956)
> ==25248==    by 0xD920AF8: ImplWindowFrameProc(vcl::Window*, unsigned short, void const*) (winproc.cxx:2524)
> ==25248==    by 0xDE6881E: SalFrame::CallCallback(unsigned short, void const*) const (in /home/julien/lo/libreoffice/instdir/program/libvcllo.so)
> ==25248==    by 0xDE78C7A: SalGenericDisplay::DispatchInternalEvent() (gendisp.cxx:86)
> ==25248==    by 0x22EEC073: GtkData::userEventFn(void*) (gtk3gtkdata.cxx:809)
> ==25248==    by 0x22EEC100: call_userEventFn (gtk3gtkdata.cxx:819)
> ==25248==    by 0x6DCDFE9: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
> ==25248==    by 0x6DCE38F: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
> ==25248==    by 0x6DCE43B: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4800.0)
> ==25248==    by 0x22EEAF11: GtkData::Yield(bool, bool) (gtk3gtkdata.cxx:467)
> ==25248==    by 0x22EEE1A2: GtkInstance::DoYield(bool, bool, unsigned long) (gtkinst.cxx:407)
> ==25248==    by 0xDD2A794: ImplYield(bool, bool, unsigned long) (svapp.cxx:511)
> ==25248==    by 0xDD265D9: Application::Yield() (svapp.cxx:553)
> ==25248==    by 0xD7CB9EE: Dialog::Execute() (dialog.cxx:887)
Comment 11 Julien Nabet 2016-04-15 16:20:38 UTC
(In reply to Stephan Bergmann from comment #10)
> Yes, the below part is interesting.  I had seen something similar too with
> my first attempt at Valgrinding this, but then unfortunately updated my JDK
> (to Fedora's OpenJDK 1.8.0.77-1.b03.fc23) and afterwards could no longer
> reproduce it.
> 
> Julien, what version of Java are you using?
> 
>...
As I put in my previous comment:
openjdk version "1.8.0_77-Debian"
OpenJDK Runtime Environment (build 1.8.0_77-Debian-8u77-b03-3+b1-b1)
OpenJDK 64-Bit Server VM (build 25.77-b1, mixed mode)
Comment 12 Caolán McNamara 2016-05-12 15:54:15 UTC
I can reproduce this on F24 with . ./instdir/program/ooenv beforehand.

Debugging into GetShortArrayRegion from libjvm in openjdk I can see that this ends up in openjdk/hotspot/src/share/vm/prims/jni.cpp in a DEFINE_GETSCALARARRAYREGION macro which has...

    if (len > 0) { \
      int sc = TypeArrayKlass::cast(src->klass())->log2_element_size(); \
      memcpy((u_char*) buf, \
             (u_char*) src->Tag##_at_addr(start), \
             len << sc);                          \
    } \

and I can plainly see that log2_element_size for the GetShortArrayRegion case is *2* so we memcpy (len << 2) bytes into the short* output rather than (len << 1) bytes. Where the log2_element_size comes from originally is opaque to me. Its extracted from _layout_helper in the klass, that is 0x80100c02, as the last two bytes. Sort of looks like a bug in openjdk, unless we somehow generate a bad original jshortArray ourselves somewhere.
Comment 13 Caolán McNamara 2016-05-12 20:04:13 UTC
hmm, so its apparently a 
[Ljava.lang.Short;
and not a 
[S
Comment 14 Caolán McNamara 2016-05-13 09:03:04 UTC
ah...
Comment 15 Caolán McNamara 2016-05-13 09:09:45 UTC
wizards/com/sun/star/wizards/table/FieldFormatter.java has new Short[] not new short[]

ecc90694175190cd6e2b9d1bed8f32850d41ce88 transformed them from new short[] to new Short[]
Comment 16 Lionel Elie Mamane 2016-05-13 09:21:58 UTC
(In reply to Caolán McNamara from comment #15)
> wizards/com/sun/star/wizards/table/FieldFormatter.java has new Short[] not
> new short[]
> 
> ecc90694175190cd6e2b9d1bed8f32850d41ce88 transformed them from new short[]
> to new Short[]

Wow, thanks for this detective work. That change looks unrelated to the commit message...
Comment 17 Commit Notification 2016-05-13 09:25:16 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: tdf#99272 new Short[] used instead of new short[]

It will be available in 5.2.0.

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 18 Commit Notification 2016-05-13 11:38:21 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1ca17f916541ba127765a9f5392fabd761cd946&h=libreoffice-5-1

Resolves: tdf#99272 new Short[] used instead of new short[]

It will be available in 5.1.4.

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 19 Commit Notification 2016-05-13 17:32:13 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

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

Related tdf#99272: Prevent bogus com.sun.star.uno.Type(Short[].class) etc.

It will be available in 5.2.0.

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 20 Caolán McNamara 2016-05-18 13:16:11 UTC
*** Bug 92580 has been marked as a duplicate of this bug. ***