Bug 197718 - [fc5] sso string implementation broken
[fc5] sso string implementation broken
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libstdc++so7 (Show other bugs)
5
All Linux
urgent Severity high
: ---
: ---
Assigned To: Jens Petersen
:
Depends On:
Blocks: SCIM
  Show dependency treegraph
 
Reported: 2006-07-05 15:05 EDT by Zack Cerza
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version: libstdc++so7-4.2.0-0.3.20060428.fc5.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-02 20:38:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
change default std::string to rc (692 bytes, patch)
2006-07-26 15:12 EDT, Benjamin Kosnik
no flags Details | Diff
package changes (9.68 KB, patch)
2006-07-27 00:50 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Description Zack Cerza 2006-07-05 15:05:33 EDT
Description of problem:
SCIM won't save the trigger hotkey.

Version-Release number of selected component (if applicable):
scim-1.4.4-9.7.fc5.i386
Comment 1 Jens Petersen 2006-07-05 21:30:02 EDT
It does for me: can you explain the exact steps
you take so that I can to reproduce?
Comment 2 Zack Cerza 2006-07-06 11:15:51 EDT
Sure:

click System->Preferences->More Preferences->SCIM Input Method Setup
click Global Setup
click the '...' button next to Trigger
click the '...' button next to Key Code
press and release Ctrl-Alt-s
click Add
click OK
click OK
click OK
click System->Preferences->More Preferences->SCIM Input Method Setup
click Global Setup
notice that the input field next to Trigger is empty again, and that Ctrl-Alt-s
does nothing
Comment 4 Jens Petersen 2006-07-11 23:58:13 EDT
I can't reproduce this.

Do you have scim running when you're doing this?
Note if scim is running you can run setup from scim command
menu by pressing the Right button on the scim icon in the systray
or on the toolbar.
Comment 5 Leon Ho 2006-07-12 00:10:42 EDT
I can reproduce this but in a different way. I got FC5 scim and tried to use
shared input mode. After SCIM restart, all of the hotkeys configuration are
emptied and I couldn't customize any keys (the fields keep in empty). I cannot
reproduce it again nor I can reset the default setting. Not sure if this is if
it is the same problem but it is pretty serious.
Comment 6 Jens Petersen 2006-07-12 01:11:22 EDT
BTW the saved config setting can be checked with:

grep /Hotkeys/FrontEnd/Trigger ~/.scim/config
Comment 7 Qingyu Wang 2006-07-12 02:50:39 EDT
I can produce this partly. The "Trigger" item is empty in the setup panal after
I setup trigger key "Ctrl+Alt+s" by the way above. But I can active or deactive
scim by "Ctrl+Alt+s" after I setup and there is /Hotkeys/FrontEnd/Trigger =
Control+Alt+s" in ~/.scim/config file. Seems it is a bug here.
Comment 8 Qingyu Wang 2006-07-12 02:51:31 EDT
I can produce this partly. The "Trigger" item is empty in the setup panal after
I setup trigger key "Ctrl+Alt+s" by the way above. But I can active or deactive
scim by "Ctrl+Alt+s" after I setup and there is /Hotkeys/FrontEnd/Trigger =
Control+Alt+s" in ~/.scim/config file. Seems it is a bug here. I will research
it in more detail soon.
Comment 9 Jens Petersen 2006-07-12 05:37:13 EDT
Yup, reproduced on FC5.  (Comment 4 was for rawhide.)
Comment 10 Qingyu Wang 2006-07-25 00:21:04 EDT
I find if I use "make" and "make install" install scim from source code, this
problem is gone. Yet if I use rpm(whatever locale build or brew build), this
problem will show up. I wonder if this is the problem of spec file of rpm.
Comment 11 Akira TAGOH 2006-07-25 02:03:29 EDT
To clarify much more, when you've tried "make" and "make install", have you
applied all the patches are available on srpm? or just from an original tarball
without any patches?
Comment 12 Qingyu Wang 2006-07-25 04:43:22 EDT
I think I applied all the patches on srpm. Because I downloaded
scim-1.4.4-9.7.fc5.src.rpm and run "rpm -ivh". And then I enter SPECS directory
run "rpmbuild -ba scim.spec", enter "BUILD" directory and scim source code
directory runing "./configure","make" and "make install".
Comment 13 Jens Petersen 2006-07-25 04:47:34 EDT
I tried building without libstdc++so7 and that seemed to fix the problem,
which would agree with comment 12 also.
Comment 14 Jens Petersen 2006-07-25 07:19:14 EDT
Also rebuilding the current scim package against
libstdc++so7-4.2.0-0.3.20060203.2 makes the problem go away for me.

I'm wondering if this problem may already have been fixed upstream in
current 4.2.  Benjamin?
Comment 15 Jens Petersen 2006-07-26 01:46:10 EDT
Here is some gdb output from the setup config module
(scim/modules/SetupUI/scim_frontend_setup.cpp (load_config))
which may shed some more light on the problem.

[ __config_keyboards [0] is the data for the main scim trigger key]

With the older snapshot:
(gdb) p __config_keyboards [0].data
$1 =
{<__gnu_cxx::_7_20060203::__rc_string<char,std::_7_20060203::char_traits<char>,std::_7_20060203::allocator<char>
>> =
{<__gnu_cxx::_7_20060203::__string_utility<char,std::_7_20060203::char_traits<char>,std::_7_20060203::allocator<char>
>> = {<No data fields>},
    static _S_empty_rep =
{<__gnu_cxx::_7_20060203::__rc_string<char,std::_7_20060203::char_traits<char>,std::_7_20060203::allocator<char>
>::_Rep> = {{
          _M_info = {_M_length = 0, _M_capacity = 0, _M_refcount = 8},
          _M_align = 0 '\0'}}, _M_terminal = 0 '\0'},
    _M_dataplus = {<std::_7_20060203::allocator<char>> =
{<__gnu_cxx::_7_20060203::new_allocator<char>> = {<No data fields>}, <No data
fields>},
      _M_p = 0x850e16c "Control+space,Zenkaku_Hankaku,Alt+s"}},
  static npos = 4294967295}

And the current one:
(gdb) p __config_keyboards [0].data
$3 =
{<__gnu_cxx::_7_20060428::__sso_string<char,std::_7_20060428::char_traits<char>,std::_7_20060428::allocator<char>
>> =
{<__gnu_cxx::_7_20060428::__string_utility<char,std::_7_20060428::char_traits<char>,std::_7_20060428::allocator<char>
>> = {<No data fields>},
    _M_dataplus = {<std::_7_20060428::allocator<char>> =
{<__gnu_cxx::_7_20060428::new_allocator<char>> = {<No data fields>}, <No data
fields>},
      _M_p = 0x93cf6e8 ""}, _M_string_length = 0, {
      _M_local_data = "#\000\000\000rol+space\000\000",
      _M_allocated_capacity = 35}}, static npos = 4294967295}

I don't know enough about the string implementation but naively it looks
like the string with the newer snapshot isn't right.
Comment 16 Benjamin Kosnik 2006-07-26 15:10:24 EDT

Yes. Some of the string configuration did change with this release of libstdc++-so7.

Specifically, I changed from rc string to sso string in GLIBCXX_ENABLE_STRING. 

I've attached a patch to revert this change. You'll need to apply it, and then
re-generate the auto* files in the libstdc++ directory. You do this by typing
"autoreconf" in the base libstdc++-v3 directory.

If you have done it correctly, then during configure you should see:

...
checking for std::basic_string base class to use... rc
....

-benjamin

Comment 17 Benjamin Kosnik 2006-07-26 15:12:08 EDT
Created attachment 133090 [details]
change default std::string to rc
Comment 18 Jens Petersen 2006-07-26 23:25:39 EDT
Okay thanks, it seems easier for me to pass "--enable-libstdcxx-string=rc"
to configure.
Comment 19 Jens Petersen 2006-07-27 00:45:21 EDT
Ok that works.  However scim needs to be rebuilt against the fixed libstdc++so7...

Since the update breaks ABI I guess it makes sense to change the
library version.  How about s/20060428/20060428_1/?
Comment 20 Jens Petersen 2006-07-27 00:50:30 EDT
Created attachment 133126 [details]
package changes

Here is a patch that implements the changes.

Does it look all right?
Comment 21 Benjamin Kosnik 2006-07-27 10:29:28 EDT
Hey Jens. Yes, you can get where you need to go with the configure option too,
and that's definitely easier.

For the library version, just stick to the date thing.

Ie: s/20060428/20060728/
Comment 22 Jens Petersen 2006-07-28 09:23:01 EDT
Ok - one last question: should the date in libstdc++-v3-so7-version.patch
be changed to 20060728 too or left at 20060428?
Comment 23 Benjamin Kosnik 2006-07-28 09:58:00 EDT
Yes please.
Comment 24 Jens Petersen 2006-07-30 21:54:07 EDT
4.2.0-0.3.20060428.fc5.3 has been built for this.
Comment 25 Jens Petersen 2006-08-01 07:39:38 EDT
scim-1.4.4-1.4.4-9.8.fc5 built
Comment 26 Jens Petersen 2006-08-02 03:49:26 EDT
All the fc5 scim IMEs have been rebuilt.
Comment 27 Fedora Update System 2006-08-02 11:02:37 EDT
libstdc++so7-4.2.0-0.3.20060428.fc5.3 scim-1.4.4-9.8.fc5 scim-anthy-1.2.0-1.fc5.1 scim-chewing-0.2.1-5.3.fc5 scim-hangul-0.2.2-2.fc5.1 scim-m17n-0.2.0-2.2.fc5 scim-pinyin-0.5.91-4.5.fc5 scim-tables-0.5.6-3.2.fc5 has been pushed for fc5, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 28 Paolo Carlini 2006-08-22 12:54:06 EDT
(In reply to comment #15)
> I don't know enough about the string implementation but naively it looks
> like the string with the newer snapshot isn't right.

Naively, I don't think you can say much from this tiny bit of info: in *both*
cases the length is zero (called, either _M_length or _M_string_length). In my
opinion, using v7 with rc-string is pointless (besides special benchmarking
purposes): if really there are problems, should be pinpointed, a reduced
testcase prepared, and fixed.

Comment 29 Jens Petersen 2006-08-23 22:42:32 EDT
(In reply to comment #28)
> Naively, I don't think you can say much from this tiny bit of info: in *both*
> cases the length is zero (called, either _M_length or _M_string_length).

I don't know about _M_length means, but the problem was in the actual
string data in _M_p I think).

> In my opinion, using v7 with rc-string is pointless

Ok, I'm just the scim package maintainer and needed a working libstdc++so7
for it and so reverted to the previous working default string implementation.
Perhaps another bug should be filed for the sso issue.

> if really there are problems, should be pinpointed,
> a reduced testcase prepared, and fixed.

Perhaps it is already fixed in cvs?  Probably it is worth trying.

Benjamin how about a newer snapshot for fc6, if it is going to be included?
Comment 30 Paolo Carlini 2006-08-24 04:03:40 EDT
(In reply to comment #29)
> (In reply to comment #28)
> > Naively, I don't think you can say much from this tiny bit of info: in *both*
> > cases the length is zero (called, either _M_length or _M_string_length).
> 
> I don't know about _M_length means, but the problem was in the actual
> string data in _M_p I think).

If length is zero, the data you find is not meaningful, just random character
that happen to be there, you cannot access past position 0!

> > In my opinion, using v7 with rc-string is pointless
> 
> Ok, I'm just the scim package maintainer and needed a working libstdc++so7
> for it and so reverted to the previous working default string implementation.
> Perhaps another bug should be filed for the sso issue.

A few punctualizations: 1- The *default* string in v7-branch is sso-string; 2-
If that string really doesn't work, for some reason, v7 should not be used at
all, in my opinion. It's something you have to check at the outset. rc-string
isn't really meant for normal use, just for benchmarking purposes!
 
> > if really there are problems, should be pinpointed,
> > a reduced testcase prepared, and fixed.
> 
> Perhaps it is already fixed in cvs?  Probably it is worth trying.

Who knows? Frankly, being the author of sso-string, I'm skeptical, but, really,
who knows? We ***badly*** need a reduced testcase and/or meaningful debugging
info. Note that in v7 there is at least another new thing, simulated move
semantics, which interacts in delicate ways with the new sso-string, in
particular when containers are involved (containers of strings), otherwise,
sso-string per-se is already well tested and well performing together with the
rest of the v6 library and mainline compiler (power users tell me that ;) To
repeat, I find simplistic just switching to rc-string in this way: v7 is a
complex beast, which should be used in experimental environments, carefully
tested, possibly *fixed* for real, and only eventually deployed.
Comment 31 Jens Petersen 2006-08-24 04:30:05 EDT
(In reply to comment #30)
> If length is zero, the data you find is not meaningful, just random character
> that happen to be there, you cannot access past position 0!

Ok :)  I'm just a user and the string length in the case above should be
non-zero in the app anyway.

> A few punctualizations: 1- The *default* string in v7-branch is sso-string

Okay - for the earlier snapshot we used this was not the case afaik.

> 2- If that string really doesn't work, for some reason, v7 should not be used at
> all, in my opinion. It's something you have to check at the outset. rc-string
> isn't really meant for normal use, just for benchmarking purposes!

The decision to use v7 for scim was not taken lightly, but pragmatically
to help work around weak symbol conflicts when used with 3rd party gtk apps
built with v5.

> > > if really there are problems, should be pinpointed,
> > > a reduced testcase prepared, and fixed.

> We ***badly*** need a reduced testcase and/or meaningful debugging
> info.

Okay, I would like to help with that but have little time right now.
If you install the previous scim packages on fc5 and it is rather
easy to reproduce fwiw.

> Note that in v7 there is at least another new thing, simulated move
> semantics, which interacts in delicate ways with the new sso-string, in
> particular when containers are involved (containers of strings), otherwise,
> sso-string per-se is already well tested and well performing together with the
> rest of the v6 library and mainline compiler (power users tell me that ;) To
> repeat, I find simplistic just switching to rc-string in this way: v7 is a
> complex beast, which should be used in experimental environments, carefully
> tested, possibly *fixed* for real, and only eventually deployed.

Okay, I see.  Could you please open another bug against fc devel about this
and we should fix that.
Comment 32 Jens Petersen 2006-08-24 04:44:28 EDT
Hmm, so perhaps it may also be a scim bug...

Anyway I'm building libstdc++so7-4.2.0-0.10.20060428.fc6 now
which reverts to the default sso string implementation.

But I really don't want to do that for fc5 until I know how to fix
any problem with scim though.

Apologies for the trouble.
Comment 33 Paolo Carlini 2006-08-24 14:07:49 EDT
An additional remark on my part: modulo gdb weirdness, as usual, the *rc-string*
data seems actually inconsistent: the length is zero, still a string is printed,
meaning there isn't a terminal '\0' in position zero, which should be always
there. there. Thus, a possibility would be that scim is working fine "by chance"
together with rc-string. It's even possible that some kind of memory corruption
is taking place. Really, we need a lot more debug info in order to properly
understand what the heck is going on...

Note You need to log in before you can comment on or make changes to this bug.