#514 Codedump while inserting Data

[Anonymous]

Hi.

I run Nedit on OpenBSD 3.9-current. If I insert the
follwing 3 chars, Nedit dumps core.

"'^

Steffen Wendzel
cdp (at) doomed (dash) reality (dot) org.

[Thorsten Haude]

Logged In: YES
user_id=119143

Please send us the first 8 lines from "Help > Version" (or the
output from "nedit -V") which will give us extra information to
help us reproduce your problem.

[Thorsten Haude]

Logged In: YES
user_id=119143

Also, please send us the output of 'ldd nedit'.

How big is the core? Could you put it up on some webspace?

[Nobody/Anonymous]

Logged In: NO

I uploaded the coredump and the version-output+lld-output here:

http://cdp.doomed-reality.org/nedit/

Steffen Wendzel

[Nobody/Anonymous]

Logged In: NO

PS. I just found out that the same problems happens if only
insert a '^'.

I start nmap and insert the '^' in the text-input and after
that, nedit dumps core.

steffen

[Thorsten Haude]

Logged In: YES
user_id=119143

How does nmap enter the picture?

With text-input you mean the main text area? What happens if
you enter the character(s) in another text field in NEdit
(eg. the find dialog)?

[Nobody/Anonymous]

Logged In: NO

The bug happens in _all_ text input areas.
* main text-area
* i-search box
* search window

I just insert the ^ (on a german keyboard you have to press
^+space for that) and nedit dumps core.

PS. s/nmap/nedit/. I make heavily use of nmap, I think thats
why I wrote 'nmap' while thinking 'nedit'.

Steffen

[Thorsten Haude]

Logged In: YES
user_id=119143

Ok, that was a bit hasty. My debugger cannot do anything
with your core:
"nedit.core" is not a core dump: File format not recognized

Could you provide a backtrace? Oh and, did you try the
binary from the website?

[Nobody/Anonymous]

Logged In: NO

Hmm... I created a completely new coredump file. But...
'gdb' says that this 'File format' is 'not recodgnized'. I
never saw such a message while using gdb and I have no Idea
what went wrong.

I just downloaded the last nedit-snapshot source code to try
this version on my OpenBSD box.

The Code compiled after i added -I/usr/local/include in
makefiles/Makefile.openbsd.

But hmm... the new binary does dump core too and the
nedit.core file does not work with gdb too.

[Nobody/Anonymous]

Logged In: NO

any idea to fix this problem?

[Thorsten Haude]

Logged In: YES
user_id=119143

I'm a bit confused about core formats here. I never
considered whether BSD and Linux would use the same core
format, but would not be suprised if they wouldn't. My GDB
may only be compiled with Linux core support.

However, you cannot open your own core? It looks like there
is more amiss there than just a coring editor. Have you
tried fiddling with ulimit to allow larger cores?

Sadly, I have no ideas about how to pursue this one.

One random idea: Did you try to use nodeadkeys? Does it
change anything?

[Thorsten Haude]

Logged In: YES
user_id=119143

Anything new on the core file?

[Scott Tringali]

Logged In: YES
user_id=11321

We really need the nedit -V version information. It's
likely you are building against LessTif. At a guess there's
something wrong with dead keys. I don't have OpenBSD around
to try it.

[Antoine Jacoutot]

Logged In: YES
user_id=542993
Originator: NO

I'd really like this bug to be fixed so I'm answering for this OP.
NEdit is compiled using openmotif-2.1.30.5 but the bug also happens if compiled with lesstif.
I'm using gcc version 3.3.5.

Here's the version info (not that the bug is reproductive on any archs I tried, x86, ppc...):

NEdit 5.5
Sep 30, 2004

Built on: OpenBSD, PowerPC, GNU C
Built at: May 31 2007, 05:58:25
With Motif: 2.1.30 [@(#)Motif Version 2.1.30]
Running Motif: 2.1 [unknown]
Server: The X.Org Foundation 70200000
Visual: 16-bit TrueColor (ID 0x23, Default)
Locale: C

And a bt:
Starting program: /usr/local/bin/nedit

Program received signal SIGSEGV, Segmentation fault.
0x0b53bebc in EffectiveStdModMask () from /usr/local/lib/libXm.so.3.0
(gdb) bt
#0 0x0b53bebc in EffectiveStdModMask () from /usr/local/lib/libXm.so.3.0
#1 0x0b53bd49 in FindVirtKey () from /usr/local/lib/libXm.so.3.0
#2 0x03ccf5f5 in XtTranslateKeycode () from /usr/X11R6/lib/libXt.so.10.0
#3 0x03ccec16 in _XtMatchUsingDontCareMods () from /usr/X11R6/lib/libXt.so.10.0
#4 0x03cd549f in MatchBranchHead () from /usr/X11R6/lib/libXt.so.10.0
#5 0x03cd5c29 in HandleSimpleState () from /usr/X11R6/lib/libXt.so.10.0
#6 0x03cd61f7 in _XtTranslateEvent () from /usr/X11R6/lib/libXt.so.10.0
#7 0x03cb1e1b in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.10.0
#8 0x03cb2902 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.10.0
#9 0x03cb2aae in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.10.0
#10 0x03cb2f3e in XtAppMainLoop () from /usr/X11R6/lib/libXt.so.10.0
#11 0x1c007b2b in main (argc=1, argv=0xcfbf4514) at nedit.c:760

[Antoine Jacoutot]

Logged In: YES
user_id=542993
Originator: NO

It seems to be a problem related to Xkeymap.

$ setxkbmap fr
and you can totally reproduce the bug.

$ setxkbmap us
and it works just fine

Any idea?

[Scott Tringali]

Logged In: YES
user_id=11321
Originator: NO

I treid this, and, while I don't have a French keyboard, I noticed some keys would insert two characters, which doesn't seem right.

That makes me suspect the real problem is that Motif doesn't support UTF8, but Xt does. Make sure your locale is set to fr_FR without UTF8 on the end:

env LANG=fr_FR nedit

If that's the case, then we are going to have to chop off UTF8 for pretty much everything. Use an iso8859-1 or -15 locale instead.

[Antoine Jacoutot]

Logged In: YES
user_id=542993
Originator: NO

Sorry I've been quite busy lately. I now have more time to try to fix this.

$ env LANG=fr_FR nedit
$ env LANG=fr_FR.ISO-8859-1 nedit
$ env LANG=fr_FR.ISO-8859-15 nedit

They all make nedit core dumps when inserting "^".