Hey DM,

I got an error this morning that I haven't seen before. Every week I run a script that creates a nodelist, nodediff, and infopack for my network. Once the files are created I hatch them into their proper directories, etc.

Seems like my nodelist and nodediff uploaded to the BBS fine, but the infopack, while residing in the correct directory, wasn't uploaded to the BBS. So I tried manually uploading with ';upload' from the file transfer menu and got:

!ERROR in upload.cpp line 40 (uploadfile) checking "agoranet.zip" access=170

Then addfiles segfaults/coredumps on trying to upload the same file.

Sep 23 08:18:23 reaper kernel: addfiles[7673]: segfault at 0 ip 00007f22426ae9ba sp 00007ffcd31e6838 error 4 in libc.so.6[7f2242626000+15f000] likely on CPU 0 (core 0, socket 0)
Sep 23 08:18:23 reaper kernel: Code: f3 0f 1e fa 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 66 <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83
Sep 23 08:18:23 reaper systemd[1]: Started Process Core Dump (PID 7674/UID 0). Sep 23 08:18:23 reaper systemd-coredump[7675]: [??] Process 7673 (addfiles) of user 1000 dumped core.

Stack trace of thread 7673:
#0 0x00007f22426ae9ba n/a (libc.so.6 + 0xae9ba)
#1 0x00005580f396b7ad n/a (/home/axisd/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.debug/addfiles + 0x247ad)
#2 0x00007f2242627cd0 n/a (libc.so.6 + 0x27cd0)
#3 0x00007f2242627d8a __libc_start_main (libc.so.6 + 0x27d8a)
#4 0x00005580f3950ab5 n/a (/home/axisd/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.debug/addfiles + 0x9ab5)
ELF object binary architecture: AMD x86-64
Sep 23 08:18:23 reaper systemd[1]: systemd-coredump@1-7674-0.service: Deactivated successfully.

Kind of at a stage of confusion here, since all 3 files are created by the same script. Two of the files are online, and one isn't. The one that isn't, can be accessed/unzipped manually just fine, and is owned by the user/group the BBS is.

I've tried 'delfiles <dir_code> -off -nol' to see if it may have been in the database and not allowing me to overwrite it, but there's nothing there to remove.

Regards,
Nick

... We are going to have peace even if we have to fight for it.
---
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Unexpected error
By: Accession to All on Sat Sep 23 2023 08:24 am

Hey DM,

I got an error this morning that I haven't seen before. Every week I run a script that creates a nodelist, nodediff, and infopack for my network. Once the files are created I hatch them into their proper directories, etc.

Seems like my nodelist and nodediff uploaded to the BBS fine, but the infopack, while residing in the correct directory, wasn't uploaded to the BBS. So I tried manually uploading with ';upload' from the file transfer menu and got:

!ERROR in upload.cpp line 40 (uploadfile) checking "agoranet.zip" access=170

That means the file is already in the directory database/index.

This should not be able to happen this deep in this code path (the check for the file's non-existence was already performed before this code where this error would be logged) - so I suspect maybe your data/dirs/<filebase>.* for this directory is corrupt. You can use 'chksmb' to check it, 'smbutil' to view it, and 'fixsmb' to repair the index if it does have a problem.

Then addfiles segfaults/coredumps on trying to upload the same file.

addfiles has been deprecated, replaced with addfiles.js: https://wiki.synchro.net/module:addfiles

Sep 23 08:18:23 reaper kernel: addfiles[7673]: segfault at 0 ip 00007f22426ae9ba sp 00007ffcd31e6838 error 4 in libc.so.6[7f2242626000+15f000] likely on CPU 0 (core 0, socket 0)
Sep 23 08:18:23 reaper kernel: Code: f3 0f 1e fa 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 66 <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83
Sep 23 08:18:23 reaper systemd[1]: Started Process Core Dump (PID 7674/UID 0). Sep 23 08:18:23 reaper systemd-coredump[7675]: [??] Process 7673 (addfiles) of user 1000 dumped core.

Stack trace of thread 7673:
#0 0x00007f22426ae9ba n/a (libc.so.6 + 0xae9ba)
#1 0x00005580f396b7ad n/a (/home/axisd/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.debug/addfiles + 0x247ad)
#2 0x00007f2242627cd0 n/a (libc.so.6 + 0x27cd0)
#3 0x00007f2242627d8a __libc_start_main (libc.so.6 + 0x27d8a)
#4 0x00005580f3950ab5 n/a (/home/axisd/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.debug/addfiles + 0x9ab5)
ELF object binary architecture: AMD x86-64
Sep 23 08:18:23 reaper systemd[1]: systemd-coredump@1-7674-0.service: Deactivated successfully.

That said, I'd still like to fix the old addfiles.c source code. Do you think you can reproduce that stack and backtrace using a debug build of addfiles for me?

Kind of at a stage of confusion here, since all 3 files are created by the same script. Two of the files are online, and one isn't. The one that isn't, can be accessed/unzipped manually just fine, and is owned by the user/group the BBS is.

The issue is that the file name you're trying to upload appears to alrady be in the filebase for that directory, at least in some form.

I've tried 'delfiles <dir_code> -off -nol' to see if it may have been in the database and not allowing me to overwrite it, but there's nothing there to remove.

Similarly, the old delfiles utility has been deprecated and replaced with delfiles.js:
https://wiki.synchro.net/module:delfiles

But if you want to examine the filebase, smbutil would be a better tool to use. --
digital man (rob)

Synchronet "Real Fact" #105:
Synchronet YouTube channel: https://www.youtube.com/c/Synchronet
Norco, CA WX: 79.9øF, 50.0% humidity, 3 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Unexpected error
By: Digital Man to Accession on Sat Sep 23 2023 02:38 pm

!ERROR in upload.cpp line 40 (uploadfile) checking "agoranet.zip"
access=170

That means the file is already in the directory database/index.

That's kind of what I figured, however, I think I'm in deeper shit than I thought with this issue. Seems as though any/all file areas that have had existing files overwritten (many FTN related areas, of course) using
'addfiles' are corrupt. I had a script for that, that's obviously outdated. ;)

This should not be able to happen this deep in this code path (the check for the file's non-existence was already performed before this code where this error would be logged) - so I suspect maybe your data/dirs/<filebase>.* for this directory is corrupt. You can use 'chksmb' to check it, 'smbutil' to view it, and 'fixsmb' to repair the index if it does have a problem.

Most definitely corrupt, as well as others it seems but this is the first to
be noticed due to a failure of any kind.

So, after running fixsmb, it seems there's still errors on it.

Orphaned Headers (!): 1
Zeroed Header Numbers (!): 1
Missing Message-IDs (!): 1

Other than that, it looks a lot cleaner than it was.

addfiles has been deprecated, replaced with addfiles.js: https://wiki.synchro.net/module:addfiles

Unfortunately, I think you told me this once before while I was trying to do some manual stuff awhile back. Now that I'm digging into scripts and seeing that I'm still using the old stuff, I guess I have some new questions:

I'm receiving FDN related files via multiple networks. This is what I assume would be a proper command syntax, but I'm not sure how addfiles.js works in regards to specifics:

jsexec addfiles.js -all -ex=files.bbs -diz -update -delete listfile:files.bbs

My thinking behind this, and correct me if I'm wrong or maybe I'll have to make a list of feature requests or something.

- Here I'm checking all directories
- Excluding uploading of files.bbs
- Checking for and using file_id.diz if it's there (here's where I'm confused with the help syntax, since it says "always extract/use description in archive" rather than "if it's there, otherwise we could do something else", hopefully this is the case, see below.)
- Updating existing file entries (This is another one that didn't seem to work the way I thought it would with the old addfiles. I'm not trying to update ALL existing file entries, which is what the old addfiles would do, if I remember right. I'm only trying to update files that are received and are overwriting an existing file (infopacks, for example). This is probably my main cause of a lot of my dirs being corrupt).
- While searching all directories, find files.bbs (listfile) and use that for uploading new files.
- Delete files.bbs after uploads

I have a feeling I'm way off on this, which is why it took me awhile to get the old addfiles working in a way I could handle. I still was never able to get it to update overwritten files, and list them as new files when doing a newscan without every file on my system becoming marked as new.

That said, I'd still like to fix the old addfiles.c source code. Do you think you can reproduce that stack and backtrace using a debug build of addfiles for me?

Sure, with detailed instructions of course (not a programmer). And I just checked to make sure the coredump still happens after using chksmb/fixsmb on that dir, it does.

Is this debug build of addfiles something you would provide me? Or while I'm using the debug version of Synchronet as a whole, do I have it already?

But if you want to examine the filebase, smbutil would be a better tool to use.

I'm not going to go any further at the moment so I don't actually fix it to where I'm not able to provide you with the stack and backtrace. ;)

Regards,
Nick

... All great discoveries are made by mistake.
---
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Unexpected error
By: Accession to Digital Man on Sun Sep 24 2023 08:26 am

Re: Unexpected error
By: Digital Man to Accession on Sat Sep 23 2023 02:38 pm

!ERROR in upload.cpp line 40 (uploadfile) checking "agoranet.zip"
access=170

That means the file is already in the directory database/index.

That's kind of what I figured, however, I think I'm in deeper shit than I thought with this issue. Seems as though any/all file areas that have had existing files overwritten (many FTN related areas, of course) using 'addfiles' are corrupt. I had a script for that, that's obviously outdated. ;)

I do want to fix the old addfiles, so at least those that still depend on it, have it working correctly. But eventually, it'll probably go away for good.

This should not be able to happen this deep in this code path (the check for the file's non-existence was already performed before this code where this error would be logged) - so I suspect maybe your data/dirs/<filebase>.* for this directory is corrupt. You can use 'chksmb' to check it, 'smbutil' to view it, and 'fixsmb' to repair the index if it does have a problem.

Most definitely corrupt, as well as others it seems but this is the first to be noticed due to a failure of any kind.

So, after running fixsmb, it seems there's still errors on it.

Orphaned Headers (!): 1
Zeroed Header Numbers (!): 1
Missing Message-IDs (!): 1

Other than that, it looks a lot cleaner than it was.

You can also use 'smbutil' to attempt repair of any correpted file bases using 'smbutil -a mp path/to/filebase.shd'

addfiles has been deprecated, replaced with addfiles.js: https://wiki.synchro.net/module:addfiles

Unfortunately, I think you told me this once before while I was trying to do some manual stuff awhile back. Now that I'm digging into scripts and seeing that I'm still using the old stuff, I guess I have some new questions:

I'm receiving FDN related files via multiple networks. This is what I assume would be a proper command syntax, but I'm not sure how addfiles.js works in regards to specifics:

Any reason you're not using TickIT for this job?

jsexec addfiles.js -all -ex=files.bbs -diz -update -delete listfile:files.bbs

"listfile:" is not part of the command-line syntax. Just name of the listfile itself (no prefix or other decoration needed).

Also, files.bbs is excluded by default, so you don't need to specify "-ex=files.bbs" on the command-line.

My thinking behind this, and correct me if I'm wrong or maybe I'll have to make a list of feature requests or something.

- Here I'm checking all directories

Yes

- Excluding uploading of files.bbs

That's the default behavior

- Checking for and using file_id.diz if it's there (here's where I'm confused with the help syntax, since it says "always extract/use description in archive" rather than "if it's there, otherwise we could do something else", hopefully this is the case, see below.)

Without -diz, an extended description in the listfile would be used instead.

- Updating existing file entries (This is another one that didn't seem to work the way I thought it would with the old addfiles. I'm not trying to update ALL existing file entries, which is what the old addfiles would do, if I remember right. I'm only trying to update files that are received and are overwriting an existing file (infopacks, for example). This is probably my main cause of a lot of my dirs being corrupt).

It would update the information for files listed in the listfile only (and only if the file is already in the filebase), otherwise, it's a regular file-add operation.

- While searching all directories, find files.bbs (listfile) and use that for uploading new files.

Yes.

- Delete files.bbs after uploads

Yes.

I have a feeling I'm way off on this, which is why it took me awhile to get the old addfiles working in a way I could handle. I still was never able to get it to update overwritten files, and list them as new files when doing a newscan without every file on my system becoming marked as new.

I just added a -readd option to addfiles.js that'll re-add any updated files so the will appear as newly-uploaded. This was what the old addfiles '-o' option would do, but may not work now (with addfiles).

That said, I'd still like to fix the old addfiles.c source code. Do you think you can reproduce that stack and backtrace using a debug build of addfiles for me?

Sure, with detailed instructions of course (not a programmer). And I just checked to make sure the coredump still happens after using chksmb/fixsmb on that dir, it does.

It'd likely be the same way you captured the pasted backtrace before, but use a "debug" (instead of "release") build of Synchronet to do it. Instructions on how to switch to a debug build are at https://wiki.synchro.net/howto:gdb

Is this debug build of addfiles something you would provide me? Or while I'm using the debug version of Synchronet as a whole, do I have it already?

You need to just use a different build (make) option.

But if you want to examine the filebase, smbutil would be a better tool to use.

I'm not going to go any further at the moment so I don't actually fix it to where I'm not able to provide you with the stack and backtrace. ;)

Okay, cool.
--
digital man (rob)

Synchronet "Real Fact" #26:
The Synchronet Web Server was written predominantly by Stephen Hurd (Deuce) Norco, CA WX: 80.7øF, 50.0% humidity, 5 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Unexpected error
By: Digital Man to Accession on Sun Sep 24 2023 01:22 pm

You can also use 'smbutil' to attempt repair of any correpted file bases using 'smbutil -a mp path/to/filebase.shd'

Yep, I'm aware of that, but haven't done it yet in order to try to get you what you need to fix addfiles.

I'm receiving FDN related files via multiple networks. This is what I
assume would be a proper command syntax, but I'm not sure how
addfiles.js works in regards to specifics:

Any reason you're not using TickIT for this job?

Yes, I'm using Husky software as my main hub to deal with all things FTN related, and it happens to be on the same VM as my Synchronet BBS. So I actually share my FDN file directories between the two, so no need for transferring .tic files and whatnot in the same VM, just needed to add the files to the BBS via addfiles over the years (and now addfiles.js, of course). If I were ever to get the motivation to redo things, I would definitely separate the two.

jsexec addfiles.js -all -ex=files.bbs -diz -update -delete
listfile:files.bbs

"listfile:" is not part of the command-line syntax. Just name of the listfile itself (no prefix or other decoration needed).

Also, files.bbs is excluded by default, so you don't need to specify "-ex=files.bbs" on the command-line.

I've changed that line to:

'jsexec addfiles.js -all -diz -update -readd -delete files.bbs'

Does this look more correct?

- Excluding uploading of files.bbs

That's the default behavior

Noted.

Without -diz, an extended description in the listfile would be used instead.

Are you referring to just the option for addfiles.js? I guess what I'm trying to do here, is search for and use a file_id.diz if it exists, if not.. use the description in files.bbs. Some people seem to hatch out files that don't use the file_id.diz as the description, or they use some short formed description instead. I'd rather use the original description that came with the file, and if THAT doesn't exist, continue with whatever the .tic file gave to files.bbs.

Are you saying that both options (-diz and files.bbs) should not be used together for addfiles.js, or can they be?

I just added a -readd option to addfiles.js that'll re-add any updated files so the will appear as newly-uploaded. This was what the old addfiles '-o' option would do, but may not work now (with addfiles).

According to the help, '-o' updates upload date only for existing files. However, it wasn't marking them as new files during a newscan. This '-readd' may just be what I've always been looking for.

With the old addfiles, I was using 'addfiles - -noz /sbbs/data/dirs/*.shd' or something similar. This worked for everything I needed, and did indeed use file_id.diz, and if it wasn't there used what was in files.bbs. The only thing it didn't do was any files that the date was updated on, were not marked as new files, so they never came up on a file newscan. Again, I think we're on to something here with the new option you just added. ;)

It'd likely be the same way you captured the pasted backtrace before, but use a "debug" (instead of "release") build of Synchronet to do it. Instructions on how to switch to a debug build are at https://wiki.synchro.net/howto:gdb

I'm fairly certain I'm using a debug version. My pasted backtrace before included /home/axisd/sbbs/repo/src/sbbs3/gcc.linux.x64.exe.debug/addfiles, but the trace itself was provided by systemd-coredump. Nothing related to SBBS, except addfiles, segfaulted. The BBS itself keeps running. That said, I'm not understanding the wiki instructions. I tried:

gdb /home/axisd/sbbs/exec/sbbs core.addfiles.1000.0ddb36cc2592412d942b61d8556aa565.180366.1695589153000000

.. as that was the only core file provided, and didn't get much help.

(gdb) bt
#0 0x00007fa996cae9ba in ?? ()
#1 0x000055f4a2460a24 in ?? ()
#2 0x00007fff6024ca18 in ?? ()
#3 0x0000000400000000 in ?? ()
#4 0x0000000000000000 in ?? ()

so I went with this part from the wiki:

or (if debugging with a core file):

# gdb /sbbs/exec/sbbs /tmp/core.sbbs.#### (using the core file mentioned above)

and ended up getting this:

#0 0x00007f4ef5eae9ba in ?? ()

so I continued with the wiki instruction..

(gdb) thread apply all bt

Thread 1 (LWP 184418):
#0 0x00007f4ef5eae9ba in ?? ()
#1 0x0000564333b67a24 in ?? ()
#2 0x00007ffe872c8ba8 in ?? ()
#3 0x0000000400000000 in ?? ()
#4 0x0000000000000000 in ?? ()

You need to just use a different build (make) option.

I always compile the debug build, just so I don't have to when something like this happens. It's a dedicated VM only for this stuff, so unless the release version runs 10x faster and smoother, I would rather stick to the debug version.

Regards,
Nick

... You'll never walk alone with schizophrenia.
---
þ Synchronet þ thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)