[SOLVED] XAMPP and proftpd - segmentation fault issues

dj_jaz_1225 · 2020-08-20 23:18:24

Hello. this is a strange problem I've never seen before, and one of my most dreaded errors: the segmentation fault

I am using up-to-date packages downloaded from their appropriate sources, following this article exactly as it says . I can't get xampp (or in this case, the lampp executable) to start proftpd.

here's the output of the command

$ sudo /opt/lampp/lampp start
[sudo] password for jaz:
Starting XAMPP for Linux 7.4.8-0...
XAMPP: Starting Apache...already running.
XAMPP: Starting MySQL...already running.
XAMPP: Starting ProFTPD.../opt/lampp/lampp: line 180: 65017 Segmentation fault      (core dumped) $XAMPP_ROOT/sbin/proftpd > $XAMPP_ROOT/var/proftpd/start.err 2>&1
fail.
Contents of "/opt/lampp/var/proftpd/start.err":

the line number 180 shows a conditional script that determines if proftpd is already running, and if it isn't then it executes it:

function startProFTPD() {

	printf "XAMPP: $($GETTEXT 'Starting %s...')" "ProFTPD"

	if testrun "$XAMPP_ROOT/var/proftpd.pid" proftpd
	then
		$GETTEXT -s "already running."
		return 0
	fi

	if testport 21
	then
		$GETTEXT -s "fail."
		echo "XAMPP: " $($GETTEXT 'Another FTP daemon is already running.')
		return 1
	fi

	$XAMPP_ROOT/sbin/proftpd > $XAMPP_ROOT/var/proftpd/start.err 2>&1

	if test $? -ne 0
	then
		$GETTEXT -s "fail."

		printf "$($GETTEXT -s 'Contents of \"%s\":')\n" "$XAMPP_ROOT/var/proftpd/start.err"

		cat "$XAMPP_ROOT/var/proftpd/start.err"

		return 1
	fi

	$GETTEXT -s "ok."
	return 0
}

and executing

cd ./sbin;sudo ./proftpd

returns the following error:

zsh: segmentation fault  sudo ./proftpd

proftpd is not like the lampp script, so I can't open the contents see what it is trying to access. any assistance with this is greatly appreciated

Last edited by dj_jaz_1225 (2020-08-22 23:19:38)

loqs · 2020-08-20 23:38:55

Core_dump#Examining_a_core_dump should reveal at least which executable failed.

dj_jaz_1225 · 2020-08-20 23:56:34

loqs wrote:

Core_dump#Examining_a_core_dump should reveal at least which executable failed.

I found some useful items out of the utilities you provided

$ coredumpctl gdb 52673
.................
                Stack trace of thread 52673:
                #0  0x00007f3bb152e38d getenv (libc.so.6 + 0x3e38d)
                #1  0x00007f3bb15d66b1 _getopt_internal_r (libc.so.6 + 0xe66b1)
                #2  0x00007f3bb15d68f5 _getopt_internal (libc.so.6 + 0xe68f5)
                #3  0x00007f3bb15d6982 getopt_long (libc.so.6 + 0xe6982)
                #4  0x00000000004169c3 main (proftpd + 0x169c3)
                #5  0x00007f3bb1517002 __libc_start_main (libc.so.6 + 0x27002)
                #6  0x000000000041737a _start (proftpd + 0x1737a)
..................
Reading symbols from /opt/lampp/sbin/proftpd...
(No debugging symbols found in /opt/lampp/sbin/proftpd)
[New LWP 52673]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `./proftpd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f3bb152e38d in getenv () from /usr/lib/libc.so.6

so it is saying it doesn't have permission to use "getenv"?

Last edited by dj_jaz_1225 (2020-08-20 23:57:20)

loqs · 2020-08-21 00:14:07

There was a segment fault (memory access violation) inside the getenv function of libc.so.6.

dj_jaz_1225 · 2020-08-21 01:18:06

loqs wrote:

There was a segment fault (memory access violation) inside the getenv function of libc.so.6.

okay, so after searching around I got no solution to the problem. how do I resolve this issue?

seth · 2020-08-21 07:02:45

Output of

sudo printenv

?

loqs · 2020-08-21 07:03:30

getopt_long uses getenv to check if POSIXLY_CORRECT is set. Is the variable set on your system?

dj_jaz_1225 · 2020-08-21 18:06:51

seth wrote:

Output of
sudo printenv
?

loqs wrote:

getopt_long uses getenv to check if POSIXLY_CORRECT is set. Is the variable set on your system?

it appears that

$sudo printenv

outputs every variable in the system, but "POSIXLY_CORRECT" is not set. what part of the script is supposed to set that variable and how do I get that to work correctly without running into memory violations? never had experience with variable setting, at least not those that are persistent across boot sessions.

seth · 2020-08-21 18:11:24

The variable doesn't have to be set, it affects how parameters read.
Please post the complete output of printenv.

dj_jaz_1225 · 2020-08-21 18:22:11

$sudo printenv
XAUTHORITY=/home/jaz/.Xauthority
TERM=st-256color
DISPLAY=:0
PATH= 
LANG=C
MAIL=/var/mail/root
LOGNAME=root
USER=root
HOME=/root
SHELL=/bin/bash
SUDO_COMMAND=/usr/bin/printenv
SUDO_USER=jaz
SUDO_UID=1000
SUDO_GID=998
$ echo $PATH | wc -c
6746

Last edited by dj_jaz_1225 (2020-08-21 18:28:54)

seth · 2020-08-21 18:25:47

Use code tags and include the path.
Though you can also "echo $PATH | wc -c".

proftpd apparentlyhad a bug where it would create a local copy of the environment, but skip large™ values. It's claimed to be fixed somehen in 2018, but the fix superficially looks less than robust and oc. they could have re-introduced it.

dj_jaz_1225 · 2020-08-21 18:30:06

I added the wc -l output when I echo the path variable. much better than having a spam load of directories broadcasted across the web.

seth · 2020-08-21 18:32:32

Ok, try to shorten that below 2048 chars.

dj_jaz_1225 · 2020-08-21 18:33:29

seth wrote:

Use code tags and include the path.
Though you can also "echo $PATH | wc -c".
proftpd apparentlyhad a bug where it would create a local copy of the environment, but skip large™ values. It's claimed to be fixed somehen in 2018, but the fix superficially looks less than robust and oc. they could have re-introduced it.

i feel like i'm beating a dead horse when i say this. how do I fix this bug where proftpd makes a local copy instead of a global update?

seth · 2020-08-21 18:37:21

how do I fix this bug where proftpd makes a local copy instead of a global update?

What?

The local environment copy is in the process memory, just shorten the $PATH variable to something sane to see whether this is the cause of the segfault.
You can eg. "export PATH=/usr/local/bin:/usr/bin" or so in the lampp script

Edit: https://github.com/proftpd/proftpd/pull/702 (old upstream bug)

Last edited by seth (2020-08-21 18:56:01)

dj_jaz_1225 · 2020-08-21 19:09:13

seth wrote:

how do I fix this bug where proftpd makes a local copy instead of a global update?
What?
The local environment copy is in the process memory, just shorten the $PATH variable to something sane to see whether this is the cause of the segfault.
You can eg. "export PATH=/usr/local/bin:/usr/bin" or so in the lampp script

THANK YOU!

it somehow works, and the global path variable remains the same! thank you so much Seth!!!!

seth · 2020-08-21 19:30:54

You may want to raise the bug upstream.

Semi-OT: why is your $PATH ludicrously long?
That sounds itself to be a bug suboptimal approach to get some specific result…

dj_jaz_1225 · 2020-08-21 22:32:38

seth wrote:

You may want to raise the bug upstream.
Semi-OT: why is your $PATH ludicrously long?
That sounds itself to be a bug suboptimal approach to get some specific result…

it's merely because I am a messy person and didn't have time to clean up my path :0
thank you again for helping me. now I just gotta figure out how to get OwnCloud to work right... because there's always a problem to solve.
it is the final obstacle to this problem i have, where I can't access the server because it doesn't have write access to the config folder (permission issue?)

dj_jaz_1225 · 2020-08-21 22:39:30

so I thought it was a permission and I may be right:
https://central.owncloud.org/t/cant-cre … valid/1255

sudo: unknown user: www-data
sudo: error initializing audit plugin sudoers_audit

I will mark this discussion as solved as soon as I get Owncloud fully operational, if that's okay.

seth · 2020-08-22 05:40:23

You should marks this thread as solved and open a new one for unrelated owncloud issues.
https://wiki.archlinux.org/index.php/Co … uct#Forums

Also: https://wiki.archlinux.org/index.php/Nextcloud

Arch Linux

#1 2020-08-20 23:18:24

[SOLVED] XAMPP and proftpd - segmentation fault issues

#2 2020-08-20 23:38:55

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#3 2020-08-20 23:56:34

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#4 2020-08-21 00:14:07

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#5 2020-08-21 01:18:06

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#6 2020-08-21 07:02:45

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#7 2020-08-21 07:03:30

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#8 2020-08-21 18:06:51

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#9 2020-08-21 18:11:24

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#10 2020-08-21 18:22:11

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#11 2020-08-21 18:25:47

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#12 2020-08-21 18:30:06

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#13 2020-08-21 18:32:32

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#14 2020-08-21 18:33:29

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#15 2020-08-21 18:37:21

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#16 2020-08-21 19:09:13

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#17 2020-08-21 19:30:54

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#18 2020-08-21 22:32:38

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#19 2020-08-21 22:39:30

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

#20 2020-08-22 05:40:23

Re: [SOLVED] XAMPP and proftpd - segmentation fault issues

Board footer