-   Slackware (
-   -   NEdit crashes on 14.0 32bit (

perseus12 10-25-2012 06:46 PM

NEdit crashes on 14.0 32bit
Anyone using NEdit on 32bits Slackware 14.0?

I have tried the v5.5 static build and it crashes on startup with segmentation fault.

Using a more recent snapshot of source built against lesstif
v0.95.2 it starts up, but as soon as you press a double key combo like ctrl-c, it crashes.

I was using the static 5.5 version successfully on 13.37.


sairum 10-28-2012 05:08 AM

I'm using it (v5.5 static compiled version) on Slackware 14.0, 64bit multilib without a single problem.


s1aw0 10-31-2012 02:17 PM


Originally Posted by perseus12 (Post 4815034)
Anyone using NEdit on 32bits Slackware 14.0?

I have tried the v5.5 static build and it crashes on startup with segmentation fault.

Do you use a UTF8 locale in Slack-14.0? If so, try starting nedit, e.g., this way:
env LANG=C nedit

perseus12 11-02-2012 01:42 PM

sairum, slaw0: I'm glad nedit is working for you - it means there is still hope for me; I thought that it was the end of an era!

No luck with locale, it crashes as normal.
~$ env LANG=C nedit
Segmentation fault

On my 32 bit installation locale is:
bash-4.2$ locale

Could that be a problem?
Also for me 'ldd nedit' produces: (0xffffe000) => /usr/lib/ (0xb7787000) => /usr/lib/ (0xb7776000) => /usr/lib/ (0xb7765000) => /usr/lib/ (0xb7709000) => /usr/lib/ (0xb7701000) => /usr/lib/ (0xb76e7000) => /usr/lib/ (0xb75b1000) => /lib/ (0xb7585000) => /lib/ (0xb7400000) => /usr/lib/ (0xb73df000) => /usr/lib/ (0xb73d9000) => /lib/ (0xb73d3000) => /usr/lib/ (0xb73d0000) => /lib/ (0xb73cc000)
/lib/ (0xb77aa000)

It is the same for both of you? Do you have a standard and full Slackware installation? I have a, ap, d, l, n, x installed completely.

If I force a core dump and then look at this with gdb I get:
Reading symbols from /tmp/nedit-5.5-Linux-x86/nedit...(no debugging symbols found)...done.
[New LWP 11516]

warning: Could not load shared library symbols for
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by `nedit'.
Program terminated with signal 11, Segmentation fault.
#0 0xb73f8108 in __overflow () from /lib/

How can I find out exactly where its crashing; I suspect it is in some X related
lib; what else can I try?


s1aw0 11-02-2012 02:26 PM

perseus12: I see my initial guess that the problem relates to UTF8 was probably wrong. I have changed my UTF8 locale settings to the stock ones (i.e., those you are using) but nedit still crashes. But, contrary to your case, it starts fine with "env LANG=C nedit".

I have stock Slackware-14.0 installation with a few libraries and programs added but none of them is used by nedit, as far as I can judge. "ldd nedit" shows exactly the same list of libraries as you listed.

Actually, I am a bit lost. I used to run nedit in Slack-13.37 with the en_US locale, and it worked fine. Will let you know if I have an idea.

perseus12 11-03-2012 06:16 AM

I decided to workaround this problem by building openmotif and using it instead of lesstif and got succees. Btw I am now using Nedit v5.6 source which I got from


I'm going to mark this thread as solved even though the problem I am having with Slackware libs is NOT solved.

Thank you all for your help.

sairum 11-04-2012 12:56 PM

Hi again!

Nedit has always been my preferred text editor (and it still is). Regarding your question, the results of both 'locale' and 'ldd' are just like yours (above). Hence, there seems to be nothing wrong with the binaries nor the environment. On the other hand, the error of the core dump referring (see reminded me of something related with a VDSO parameter in the kernel. This is a long shot, but might be worth trying. Nowadays, in my 3.6 Kernel configuration I have "Processor type and features"--->"Compat VDSO support" set to N (none), but I recall a time where setting this to N would break a lot of things, especially if "old" software was involved. The kernel help says:

│ Map the 32-bit VDSO to the predictable old-style address too. │
│ │
│ Say N here if you are running a sufficiently recent glibc │
│ version (2.3.3 or later), to remove the high-mapped │
│ VDSO mapping and to exclusively use the randomized VDSO. │
│ │
│ If unsure, say Y. │

You may try enabling or disabling it, depending on its default state.


perseus12 11-05-2012 07:15 AM


Yes nedit has always been my preferred ed as well, although because of the recent problem with nedit I discovered 'geany' and I like it very much for python programming.

As to your suggestion: I don't know what Slackware's stock kernels use but I have always had VDSO=y because that was the default (now running 3.2.33) and nedit was OK. You may be right about vdso, however I now
think that the culprit is 'lesstif' (perhaps + vdso), because keeping everything the same, if I use lesstif nedit crashes, if I use openmotif nedit works better than it has ever worked. What I mean by that is it responds faster now and a big irritation is gone: the open file dialog has two panel areas: left = select directory and the right for selecting files. With lesstif the right area was always tiny so I have to constantly expand it manually, but with openmotif the fileopen dialog adjusts itself to the size of longest dir name AND file name.

I should have switched to openmotif years ago :-) If you feel like it, give openmotif a try and let us know your findings.

s1aw0 11-10-2012 11:34 AM

I became curious about the problem and rebuilt nedit from source applying a patch from Arch Linux' repository. The stock lesstif library was used.

The new nedit works fine both in en_US and en_US.UTF8 locales. The left panel for choosing a file adjusts itself to the longest directory name.

Since I am using a UTF8 locale, I'm glad I don't have to set env LANG=... anymore. Thanks! :-)

aihaike 01-07-2013 03:35 AM


I had to switch from en_US.UTF_8 to en_US to make nedit v5.5 running on slackware 14.0 32bit.


All times are GMT -5. The time now is 10:03 PM.