Previous Thread
Next Thread
Print Thread
almalinux, ftp, libashnet undefined symbol #37489 07 Aug 24 08:46 PM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
.run ftpdlx
FTPDLX Test
HOST: prod1test
Username: oedwards
Password: x
HOSTDIR:
HOSTFILE:
LOCALPATH:
OPCODE: 0)Host->PC bin, 1)PC->Host bin, 2)Host-PC ascii, 3)PC-Host Ascii
(add 16 to suppress the error message dialog on errors)
(add 32 for passive mode, add 128 to create c:\debug.log)
(add 256 for SFTP protocol)
Enter OPCODE: 256
Enter PORT [22]:
%Unable to load libashnet:
/lib/libashnet.so.1: undefined symbol: msStrcpy
STATUS=-5 EMSG=

Trying to do a tab(-10,22) to ftp a file over from my almalinux , i get an error box ftpdlx and then ashell crashes. when i try running ftpdlx i see the above unable to load libashnet: error message.
[root@prod1test lib]# ls libashnet* -la
lrwxrwxrwx. 1 root root 39 Jul 3 07:12 libashnet.so.1 -> /vm/miame/bin/libashnet.so.1.14.192-el9

What am i missing?
.

Last edited by Valli Information Systems; 07 Aug 24 09:01 PM.
Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37490 07 Aug 24 09:49 PM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
It appears that the libashnet 1.14.192 library build had a dynamic link dependency on a function that is no longer in the executable. I think you should be able to fix it by updating the library to:

libashnet.so.1.14.197-el9.tz

Make sure you unlink and relink /usr/lib/libashnet.so.1 to the new module; it should look something like this:
Code
$ ls -l /usr/lib/libashnet.so.1
lrwxrwxrwx. 1 ashell ashell 48 Aug  7 14:38 /usr/lib/libashnet.so.1 -> /vm/miame/bin/libashnet.so.1.14.197-el9

On a side note, note that FTPDLX has been retired; calls to it are redirected to FTP2. In theory it shouldn't matter (i.e. FTP2 is intended to be upward compatible), but there may be some differences in behavior (particularly the error codes) so to the extent you're doing any programming work with it, you should probably pivot to calling FTP2 directly (and using its documentation).

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37491 07 Aug 24 11:24 PM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
that error is corrected, thanks however my ftp transfer still crashes ashell

.type ftp.bas
MAP1 A$

? tab(-1,0)


? tab(-10,22);"0";"/vm/miame/dsk10/055999/eismnt.csv";CHR$(126);"C:\ATE\test.csv";CHR(127);

XCALL ACCEPN,A$




END
from the linux ashlog.log
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> SIGHUP trapped on: TSKAAA (root)
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> (Waiting for kbd wait to generate e
rror; tinstate=1, rlock=0)
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> (Now in kbd wait; setting basic erro
r #250)
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> ABasic Error #250 (Hangup signal (SIG
HUP) received) at location counter 68 (untrapped - program aborting)
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> Job 1 condev updated from ?ts/0:12149
55 to tsk:1214955
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> Job in kbd wait; cleaning up qflock
& exiting.
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> jobtbl refresh #2
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> 07-Aug-24 17:19:56 [TSKAAA,1,FTP,root
,tsk:1214955,totjobs=68] License recount(2)
Was: 1P/1L, Is: 0P/0L (free passes: 0 tty, 0 ip, 0 ch), GrpUsg:0,0,0

07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> Out: Nodes Remaining = 0P/0L, 75 read
s, 0 writes, 169 kbd bytes
07-Aug-24 17:19:56 [tsk:1214955-1]<FTP:68> After qpurge & qclose[root@prod1test
miame]#

from the local ate ashlog.log
07-Aug-24 17:16:07 [LAPTOP-6TN1MS53:750-0]<TELNET:6> xcall_error(FTPDLX,3)
07-Aug-24 17:16:07 [LAPTOP-6TN1MS53:750-0]<TELNET:6> Auto-expanding ATE buffer from 3070 to 6140 bytes in TAB(-10,20)...
07-Aug-24 17:16:07 [LAPTOP-6TN1MS53:750-0]<TELNET:6> Auto-expanding ATE buffer from 6138 to 12276 bytes in TAB(-10,20)...
07-Aug-24 17:16:07 [LAPTOP-6TN1MS53:750-0]<TELNET:6> Auto-expanding ATE buffer from 12274 to 24548 bytes in TAB(-10,20)...

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37492 07 Aug 24 11:47 PM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
if i use the mx_agwrapper it is successful

xcall MIAMEX, 177, 22, "0/vm/miame/dsk10/055999/mailer.csv~c:\ate\test.new~4096",response$

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37493 08 Aug 24 12:00 AM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
Hmmm... confused

Let me try to reproduce this. The log seems to suggest that it may be ATE which is crashing (generating the SIGHUP). You might want to try the Help > Check For Updates to make sure it's not just an old version issue.

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37494 08 Aug 24 12:09 AM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
okay update from .62 to .70, now i get this

/usr/bin/ate: line 6: 1217980 Segmentation fault (core dumped) /vm/miame/bi
n/ashell -d -i /vm/miame/miame.ini
[root@prod1test oedwards]#

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37495 08 Aug 24 12:15 AM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
make that 7.0.1752.0 to 7.0.1760.0

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37496 08 Aug 24 12:15 AM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
It seems to work ok for me here, using the equivalent of your test program ...
Code
MAP1 A$,S,1

? "Test using tab(-10,22) ..."

? tab(-10,22);"0"; "/vm/miame/dsk0/908068/test.csv"; chr$(126); "c:\ate\test.csv"; chr$(127);

xcall ACCEPN, A$
? "(Success)"

? "Test using MX_AGWRAPPER..."
xcall MIAMEX, 177, 22, "0/vm/miame/dsk0/908068/test.csv~c:\ate\test.new~4096",A$

? "response: "; asc(A$)
end

With the ATE TRACE turned on in the System Message window, the traces are:
Code
0 17:10:55 <TELNET:4c97> TAB(-10,36);
1 17:10:55 <TELNET:4c97> Setting KS_HOLD for tab(-10,36)
2 17:10:55 <TELNET:4c97> TAB(-10,87);0
3 17:10:55 <TELNET:4c97> TAB(-10,85);5,RUN,1.1(100)
4 17:10:55 <TELNET:4c97> TAB(-10,87);0
5 17:10:55 <TELNET:4c97> TAB(-10,85);5,FTPTST1,0.0(0)
6 17:10:55 <TELNET:4c97> TAB(-10,22);0/vm/miame/dsk0/908068/test.csv~c:\ate\test.csv
7 17:10:55 <TELNET:4c97> -> send response (kbd):  (1 bytes, icc=0)
8 17:10:55 <TELNET:4c97> sending kbd response directly (1 bytes): 
 <
9 17:10:55 <TELNET:4c97>  sendkbd exit sts: 0x20
10 17:10:55 <TELNET:4c97> TAB(-10,49);
11 17:10:55 <TELNET:4c97> Releasing KS_HOLD
12 17:10:55 <TELNET:4c97> TAB(-10,88);!
13 17:10:55 <TELNET:4c97> Setting KS_HOLD for tab(-10,88)
14 17:10:55 <TELNET:4c97> -> send response (kbd):  (1 bytes, icc=0)
15 17:10:55 <TELNET:4c97> sending kbd response directly (1 bytes): ! <
16 17:10:55 <TELNET:4c97>  sendkbd exit sts: 0x20
17 17:10:55 <TELNET:4c97> Reading (kbdsts=0x20, guists=0x2e1) ...
18 17:10:55 <TELNET:4c97> Rcv 59 bytes
19 17:10:55 <TELNET:4c97> TAB(-10,22);Þ0/vm/miame/dsk0/908068/test.csv~c:\ate\test.new~4096
20 17:10:56 <TELNET:4c97> -> send response (kbd):  (1 bytes, icc=0)
21 17:10:56 <TELNET:4c97> sending kbd response directly (1 bytes): 
 <Þ
22 17:10:56 <TELNET:4c97>  sendkbd exit sts: 0x20
23 17:10:56 <TELNET:4c97> Reading (kbdsts=0x20, guists=0x2e1) ...
24 17:10:56 <TELNET:4c97> Rcv 34 bytes
25 17:10:56 <TELNET:4c97> TAB(-10,49);
26 17:10:56 <TELNET:4c97> Releasing KS_HOLD

The main difference between your two variations is the explicit 4096 in the second version, which forces ATE to use FTP2. If you were on an older ATE, the default for the tab(-10,22) would have still been FTPDLX. So in the first case it was trying to use FTPDLX and crashing, and in the second case it was using FTP2 and succeeding. If that theory is correct, then an ATE update should fix it. (Or specify the 4096 flag.)

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37497 08 Aug 24 12:17 AM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
<crossed paths>

So the update didn't resolve this issue. But the new error is baffling -- what is "/usr/bin/ate" ???

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37498 08 Aug 24 12:29 AM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
I suggest adding TRACE=ATE,XDEBUG to the c:\ate\miame.ini, and using SET TRACE ATE ON on the server prior to running your test program. If you get the core dump, there should be a file core??? in the miame directory on the server (with a ton of details), along with a message in the ashlog.log itself (with the traces acttivated). Somewhere between the two ashlog.log files and the corelog file maybe there will be a useful clue.

We both should be on the same versions of A-Shell and ATE at this point; the main difference would be CentOS 9 vs AlmaLinux (and possibly different FTP packages / configurations.

Another detail which might be useful to test would be to add the 256 (SFTP) opcode/flag (see FTP2 opcodes) to the TAB(-10,22) command, i.e. add "~4352" to the end, and change the 4096 in the MX_AGWRAPPER version to 4352, in both cases changing the protocol from FTP to SFTP. Aside from the fact that FTP is largely deprecated these days, switching protocols would help pin down whether the issue is tied to the transfer protocol or something in the A-Shell/ATE communication.

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37499 08 Aug 24 01:49 AM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
same results, guess i'll just switch the code to use the xcall miamex call instead of the (-10,22) call. ashell is 7.0.1761.0,

MIAMEX call that works ie no coredump

07-Aug-24 19:48:14 [LAPTOP-6TN1MS53:fc0-0]<TELNET:0> TAB(-10,22);Þ0/vm/miame/dsk10/055999/test.txt~C:ATE\test.csv~4352
07-Aug-24 19:48:14 [LAPTOP-6TN1MS53:fc0-0]<TELNET:0> ateftp (4352, /vm/miame/dsk10/055999/test.txt, C:ATE\test.csv, 0)
07-Aug-24 19:48:14 [LAPTOP-6TN1MS53:fc0-0]<TELNET:0> using FTP2...
07-Aug-24 19:48:14 [LAPTOP-6TN1MS53:fc0-0]<TELNET:0> -> send response (kbd): (1 bytes, icc=0)
07-Aug-24 19:48:14 [LAPTOP-6TN1MS53:fc0-0]<TELNET:0> sending kbd response directly (1 bytes):


(-10,22) coredump
07-Aug-24 19:44:10 [LAPTOP-6TN1MS53:fc0-0]<TELNET:6> TAB(-10,22);0/vm/miame/dsk10/055999/test.txt~C:\ATE\test.csv~4352
07-Aug-24 19:44:10 [LAPTOP-6TN1MS53:fc0-0]<TELNET:6> ateftp (4352, /vm/miame/dsk10/055999/test.txt, C:\ATE\test.csv, 0)
07-Aug-24 19:44:10 [LAPTOP-6TN1MS53:fc0-0]<TELNET:6> using FTP2...
07-Aug-24 19:44:10 [LAPTOP-6TN1MS53:fc0-0]<TELNET:6> -> send response (kbd): (1 bytes, icc=0)
07-Aug-24 19:44:10 [LAPTOP-6TN1MS53:fc0-0]<TELNET:6> sending kbd response directly (1 bytes):
<

the only difference i see is the extended character after the 22); and before the 0/vm ?

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37500 08 Aug 24 02:02 AM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
That extended character is part an extra lead-in used in by MX_xxx routines to help sync with ATE. I doubt that’s the issue here.

I’m curious whether the sample program I listed above has the same problem as your test program. And wherher the server-side ashlog and/or corelog files have any salient details.

Of course you can just pivot to the working version, but if you want to get to the bottom of this another possibility would be to set me up to be able to connect to your server from my office.

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37501 08 Aug 24 02:20 AM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
yes yours did, the only difference was i had mapped a$ as s,0 you s,1 so it wasn't the tab(-10,22) it was the xcall accepn

thanks

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37502 08 Aug 24 02:25 AM
Joined: Jun 2001
Posts: 425
V
Valli Information Systems Online Content OP
Member
OP Online Content
Member
V
Joined: Jun 2001
Posts: 425
In my code, A$ was an unmapped variable so it appears it has to now be ,s,1

thanks again

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37503 08 Aug 24 02:28 AM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
Ahhhhh! Your original code sample at the top didn’t show any type, making me wonder about it. But I didn’t think of the s,0 possibility. Unfortunately s,0 is a special case in that until the variable is assigned a value via a high-level ASB statement, it doesn’t have a memory location, and XCALLs (low-level) often assume they were passed a valid memory location. I probably need to add some defensive code to ACCEPT to look out for this possibility.
Sorry for the runaround!

Re: almalinux, ftp, libashnet undefined symbol [Re: Valli Information Systems] #37504 08 Aug 24 03:53 PM
Joined: Jun 2001
Posts: 11,794
J
Jack McGregor Offline
Member
Offline
Member
J
Joined: Jun 2001
Posts: 11,794
Just to put a ribbon on this, I've confirmed that xcall ACCEPN,A generates a segmentation fault if A is mapped as a dynamic string (S,0 or X,0). But it's fine if mapped as any other type. Or unmapped (which is equivalent to S,10, or whatever STRSIZ is defined as).

That loophole will be closed in 7.0.1761.3 (along with any similar ones found after a more thorough review). But it's probably not a big practical concern, since it doesn't really make any sense to use a dynamic variable for storing data known to be fixed in size, or variable but less than about 20 bytes. (Dynamic variables have 16 bytes of extra descriptor overhead before they even get allocated, and the management of the allocated storage pools for dynamic variables has plenty of additional CPU and memory overhead. So although they may be convenient, from an efficiency standpoint, they only really make sense in situations where you don't know how big the data could get.) Unallocated dynamic variables can cause problems like this with some XCALLs, especially very old ones, that were translated from assembler code and/or designed for maximum CPU efficiency (perating directly on memory addresses via pointers.)


Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3