Dear All,
I am retaking the issues with regard to a segmentation error that happens on SU modules after successful compilation. I have been compiling and testing several releases of CWP-44 versions on UBUNTU 22.04 LTS. The issue is that after successful compilation when I try and run any of the modules, an immediate segmentation error occurs, and the documentation is not printed out. when using the debugger, I get always the same message independently of the executable ( a2b, sunan, etc).
-------------------------------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
__vfprintf_internal (s=0x555642a0, format=0x55555555c292 "%s\n", ap=ap@entry=0x7fffffffbe50, mode_flags=mode_flags@entry=0) at ./stdio-common/vfprintf-internal.c:1218
1218 ./stdio-common/vfprintf-internal.c: No such file or directory.
(gdb) where
#0 __vfprintf_internal (s=0x555642a0, format=0x55555555c292 "%s\n", ap=ap@entry=0x7fffffffbe50,
mode_flags=mode_flags@entry=0) at ./stdio-common/vfprintf-internal.c:1218
#1 0x00007ffff7c6074a in __fprintf (stream=<optimized out>, format=<optimized out>) at ./stdio-common/fprintf.c:32
#2 0x0000555555556b2d in pagedoc () at docpkge.c:126
#3 0x0000555555556a09 in requestdoc (flag=1) at docpkge.c:95
#4 0x00005555555567e6 in main (argc=1, argv=0x7fffffffc118) at a2b.c:55
------------------------------------------------------------------------------------------------------------
However the problem starts at release R20, Up to R19 the entire CWP-SU works OK, no segmentation errors, form R20 onwards the distributions are useless on UBUNTU 22.04 LTS. (I have tried on 3 different machines to make sure it was not a set up issue).
CWP-44.R18 fine
CWP-44.R19 fine
CWP-44.R20 segmentation errors
CWP-44.R22 segmentation errors
CWP-44.R25 segmentation errors
CWP-44.R26 segmentation errors
CWP-44.R27 segmentation errors
If anybody has any idea It would be welcome. Thanks.
Dear All,
I have been able to compile CWP-44.R26 with the changes in the Makefile.config
I have added as suggested:
POSTLFLAGS = -ltirpc
OPTC = -g -std=c99 -m64 -Wall -ansi -Wno-long-long -D_ISOC99_SOURCE
CFLAGS = -I$I $(OPTC) $(CWP_FLAGS) $(shell pkg-config --cflags libtirpc)
THe compilation was successful, However an even more strange thing happens now. The generated executables have an segmentation fault when they are called without arguments
eg:
Executing a2b (for example)
nmrc@BlueDawn /home/nmrc/ > a2b
zsh: segmentation fault (core dumped) a2b
Nevertheless, with an input file the executable works correctly,
Has anybody by any chance encountered this issue before? Any ideas how to solve it?
This behaviour gets worse as grafics (xgraph, xwigb, ximage and their su equivalents don't work even with arguments).
suximage perc=98 <
tst.su /home/nmrc/sys.r/sft.local/CWP/bin/ximage: error reading input file
zsh: segmentation fault (core dumped) suximage perc=98 <
tst.su
Thanks in advance.
Ramon
Okay, this is the first time I hear that people want XDR. So we can't back out of it. --- Shuki
Hi All,
Thanks all for the reminder about the idiosyncracies of Ubuntu. But, just to add 2c to the discussion, like quite a number of other people and
companies (including work at CSM) , I've been using SU interactively mixed with java, which latter writes native bigendian floats. It was a joy to enable the XDR versions
of SU where I didn't have to worry about endianity all the time, and scripts didn't need to be littered with swapbytes stuff.
So I'd urge caution in removing functionality that many have appreciated immensely.
Thanks
James.
James Gunning
CSIRO
Clayton, Vic., Australia
Let's stop and think if we need XDR in SU. At the beginning SU used native endian and floating point format. Users knew that when moving from one computer to another, byte swap and floating point format might be needed. SU was developed
on a VAX at Stanford and when I took it to CSM on a compute Gould there there was a factor of 4 in the floating point numbers. Later people lived with moving data between big and small endians, it was sometimes a nuisance but not nearly as much of a problem
as XDR is now. Because SU can be compiled with or without XDR, usually without the users being aware of it, there is often a situation that people on the same type of computer are incompatible. Aegrescit medendo.
What I suggest is
1. Back out SU off XDR. Go back to pre XDR gettr and puttr. I may still have an old version of SU but it's simple.
3. Provide either data conversion tools and/or functionality in gettr to convert the data to native format--we don't need XDR to do that.
4. The unsigned short ns header word limits the number of samples per trace to 65K. This was plenty in 1975 when SEGY was new but not now. If somebody simplifies SU taking it off XDR then they can easily designate a fall back 32 bit header word to
be used if ns is set to zero.
--- Shuki
Seisunix mailing list -- seisunix@mailman.seismic-unix.org
To unsubscribe send an email to seisunix-leave@mailman.seismic-unix.org
--
Ramon
--------------------------------------------------------------------------------------------
Ramon Carbonell
--
Ramon
--------------------------------------------------------------------------------------------
Ramon Carbonell