On Sun, Nov 24, 2002 at 12:49:35PM -0800, Nadim Shaikli wrote:
> --- Ethan Blanton wrote:
> > Nadim Shaikli spake unto us the following wisdom:
> > > Ideally it would be wonderful to simply run fvwm and this code
> > > under a debugger and single step around for a better feel for
> > > what is causing it to go into the weeds.
> >
> > How about running your debugger/fvwm in a screen session? You can
> > then connect to that screen session once X is started up and work
> > from there, and if it bombs out you can restart X and connect to
> > the crashed session for some post-mortem analysis.
>
> **AND**
>
> --- Mikhael Goikhman wrote:
> > If you don't want your windows to go down, just verify that X does
> > not go down. This may be achieved if you start fvwm in the background
> > using "&" and xterm in the foreground in ~/.xinitrc, so that you may
> > recompile and launch another fvwm from this (or another) xterm.
>
> With both suggestions in-hand, I tried to run a debugger on fvwm while
> running it (I've never done such a thing) and needless to say it was
> a major pain with lots of freezing and rebooting, etc. In short, I
> didn't get anywhere.
>
> I do have a possible idea of what is happening. Mikhael/Olivier, this
> might make sense to you guys more than others :-) so let me know if you
> want further detail off the list. I added a continuous assignment to a
> Form-B glyph right above the first '#if 0' in the FBidiJoin.c file (say
> to 0xFED3) and that failed. Which leads me to believe that unicode
> conversion within fvwm is failing (this would also explain why the same
> code doesn't fail outside fvwm). Does this make sense or ring any
> bells ? In other words, a glyph value of 0x0641 is fine where as 0xFED3
> seems to trigger memory stomping - the difference there is how UTF-8 is
> represnted and converted (are all UTF-8's within fvwm represented as
> 4-bytes since that could be the max size ?
No and it should not. UTF-8 is not UCS-4. Do I miss somthing?
> The difference in the example
> noted above it 2-bytes vs. 3-bytes). Am I barking up the wrong tree :-) ?
>
Ok, I've found the problem. FBidiConvert assume that the "in" string
and the "out" string have the same length. This is the case until you
joint. With joint what may happen is:
UTF-8 src string have length 34 (as char *)
--> convert into UCS-4, the string has length 20 (as char32 *)
--> apply bidi algo, the string has length 20 (as char32 *)
--> apply joint algo, the string has length 20 (as char32 *)
--> convert back to UTF-8, the string has length 40 (as char *)
----> core dump
the length of the returned string (visual_str) should be computed
after the joint algo is performed. BTW, fribidi should know the length
of the result of fribidi_unicode_to_charset before you call it, this
is a very very strange way to implement a converter!!
So we need the function:
USC4UTF8Length(Char32 *str): return the length of an UCS-4 string
considered as an UTF-8 string
and also the following function will be useful (to allocate
logical_unicode_str at exact size):
UTF8USC4Length(unsigned char *str): return the length of an utf-8 string
considered as an USC-4 string
a simple workaround is to replace
visual_str = (char *)safemalloc((str_len + 1) * sizeof(char));
by
visual_str = (char *)safemalloc((4*str_len + 1) * sizeof(char));
I do not have the time to write down the fix in the next 5 days (at
least two others thing todo before: IconMan and LocalePath).
Mikhael, Nadim ?
Regards, Olivier
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
