I run Nedit on OpenBSD 3.9-current. If I insert the
follwing 3 chars, Nedit dumps core.
cdp (at) doomed (dash) reality (dot) org.
Logged In: YES
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.
Also, please send us the output of 'ldd nedit'.
How big is the core? Could you put it up on some webspace?
Logged In: NO
I uploaded the coredump and the version-output+lld-output here:
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.
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)?
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'.
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?
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
But hmm... the new binary does dump core too and the
nedit.core file does not work with gdb too.
any idea to fix this problem?
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
Anything new on the core file?
Logged In: YES
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.
Logged In: YES
I'd really like this bug to be fixed so I'm answering for this OP.
NEdit is compiled using openmotif-220.127.116.11 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...):
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)
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
#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
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
Logged In: YES
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.
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 "^".
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.