invalid next size #7
Comments
|
please compile it with debug info and try to either get core dump or attach debugger to the crash (debug info can be enabled by editing Makefile.config and changing -O2 to -g, you can attach debugger by adding some Sleep() into the main code and attaching gdb to the pid while it sleeps) |
|
Hi See the following in dmesg: Also current the line inside Makefile.config is not with O2 but O0, what else can i do for you to grab you more details? |
|
Extra information: It appears when you just site pre a empty dir nothing goes wrong: As soon the directory contains any files then it gives the malloc(): invalid next size (unsorted) |
|
you might want to try https://github.com/silv3rr/foo-tools |
|
Hi silv3rr, Compile goes perfect but shows the same behaviour :( |
|
Hi I've added sleep(60); inside the code off: int pre(char *section, char *dest, char *src, char *rel, char *group, char *argv[]) { within glftpd site pre dir section, the proccess fall into sleep. After that i attach gdb to the process: For help, type "help". |
|
I found out with next i can show more information: Attached the output of gdb before it reaches a SIGABRT |
|
thanks nice progress after the SIGABRT do a "bt full" to get info where it happened also you can use "step" to go into the function where it crashed (userfile_update) instead of using next |
|
Hi See the 2 files added it shows a more detailed overview what happens, i'll try to do some more with using step :) |
|
thanks ill have a look |
|
I dont see an error directly around the point of crash just yet but the error indicates a memory corruption which could have happened earlier. Could you compile with these flags which might give us the error when it happens ? |
|
Hi I've changed Makefile.config to have the line CC = gcc -g -fsanitize=address -fsanitize=undefined -D_FORTIFY_SOURCE=2 -fstack-protector-all which give a shitload off error :) but foo-pre does compile but as soon you run it: site pre the following error show within glftpd (after a few libs have been copyed to /lib dir inside glftpd) [10:50:19] [L] site pre Here the small log within ../pre/ |
|
ok but what happens when you add the sleep and use the gdb like before ? those compilation warnings just mean the code is crap but everyone knew that :) |
|
Hi, placed the sleep inside: int main(int argc, char *argv[]) { [11:27:59] [L] site pre |
|
Running the ./foo-pre from command line and attached gdb: For help, type "help". Did not find environment for glftpd, please run only from within glftpd as 'site' command! |
|
I've added the sleep inside this code: int pre_handler(int argc, char *argv[]) { gdb -p 10291 For help, type "help". Program received signal SIGABRT, Aborted. |
|
Hmm, Ok, i've removed sleep(60); and edited: from: to: this to disable the updateing of userfile at all, foo-pre runs properly then and no mistakes inside the logs. releasedir moved to destination and output as follows: [12:21:23] [L] site pre TEST4-GUEST mp3 |
|
not sure if related but you could try setting addmp3genretogllog=1 in pre.cfg also, make sure chown user/group set in pre.cfg group exist in gl's passwd/group file |
|
Hi, [14:19:25] [R] 200- *** Error in `/bin/foo-pre': free(): invalid next size (fast): 0x00005631cad48b90 *** Will add debug for it. |
|
Copyed libgcc_s.so.1 to the lib dir inside glftpd: Following stuff is shown now: (Debian 9) At this point there has been no logging inside glftpd.log at all. |
|
On try02 you'll see the output not with gdb but with strace. |
|
Ok gimmie some input if possible, i've been adding some code to disable updating userfile as show earlier above, the next size error is gone. So i have been checking inside:
From there i've narrowd down how far the code normaly excecude until the error show inside the client. Added is the code off userfile_update try03.txt Code: /* edited to see if the error next size is gone */ inside the file is where i gues errors are because if that code is executed we face the errors from try01.txt |
|
as its a memory corruption issue that happens first but is detected later in the code it would be hard to figure out by commenting out code this way. I would highly recommend either using tool like asan (i showed the flags before) or valgrind to find the exact cause or find some way to replicate the issue so i can fix it myself. |
|
Hook me up a bit how i could use asan or valgrind. The flags you showed before make the excecutable not being able to ran inside like glftpd when running site pre. Don't you have the issue on Debian 10 or 9. |
|
valgrind --leak-check=full --show-leak-kinds=all ./foo-pre This show when just run valgrind on the build foo-pre excutable. |
|
Remember that you need to run the full command that crashes under valgrind. foo-pre runs chrooted so you might need valgrind under the chroot too. Another option is to run the inetd under valgrind and have it follow child processes. Neither is simple. Also you want to detect memory corruption and not leaks so you have to put that into the command line too. Using asan or something like that might still be easier option but hard to say. |
|
I’ll add it to the chroot and run from there. -tool=memcheck -v any other you’d like to see? |
|
I've been playing and thinking more, if i change the following 2 lines from pre.cfg errors are gone. countable=.none All sort of dirs i've tryed and it pred without errors, but as soon the dir contains any files with *.none extension the error is back. So i really think it's something todo with that. What you think?? i'm not a pro in all this :) |
|
If the error shows up, the userfile USER.pre-tmp still exist, and rename(ufnew, userfile); from gl_userfile_add_stats never be reached it seems. Just the file is half written: USER Added by glftpd |
|
Compared to the original line in the userfile: ALLUP 530 61055486 5707 1410 26925160 1567 13 212849 13 0 0 0 17926 131282104 18240 0 0 0 4458 407089604 7775 0 0 0 After the ALLUP it stops and leave the file. |
|
disable: and: |
|
Hi Ive found out change your userfile change all to 0 and it works ALLUP 19 91428 2 21 94540 21 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 |
|
ALLUP 530 61055486 5707 1410 26925160 1567 13 212849 13 0 0 0 17926 131282104 18240 0 0 0 4458 407089604 7775 0 0 0 this was in the USER file before. what to change to have the old file with stats working? |
|
From a quick glance looks like it could be related to stat_sections Adding ALLUP, WKUP etc stats (and creds) are handled in foo-tools/src/pre/gl_userfile.c by You could try testing only using the default stat section in gl and pre conf I'll try to have further look if time permits |
|
hi! tested with just having 1 stat line in glftpd.conf: here the result: At this moment i have been able to reproduce this error on different debian 9 and 10 systems |
|
Hi, Found out the if the glftpd.conf have more stats_section which also have multiple [:and:] in the lines aswell it fails like: disable one of the 2 and it works. |
You should always leave the default first in gl conf: Also make sure your stat_sections match pre.cfg sections ( foopre probably messes up trying to find stat_sec while adding stats to userfile. Ill see if i can add a better check. |
|
Hi! If you use different stat_section with own credits then yes, but his problem looks more like a low buffer to add stats. I would suggest to increase the buffer inside gl_userfile.c are your stats for certain section bigger then > 0123456789? Just make sure you have the first stat_section DEFAULT * yes/no the yes or no is for if credits are to be counted seperately if you not add it the default is no I’ll upload my foo-tools and you could try that aswell. |
|
MickMouse, is your issue fixed or still experience problems? |
Hi,
Grab this latest git and compile on latest Debian 10.2.
When try to test pre:
[14:02:47] [L] site pre TEST-UNKNOWN mp3
[14:02:47] [L] 200- malloc(): invalid next size (unsorted)
[14:02:47] [L] 200- Aborted
[14:02:47] [L] 200 Command Successful.
The text was updated successfully, but these errors were encountered: