Caldera on linux with SIGSEGV error
- Thread starter PNAI
- Start date
Condobloke
Well-Known Member
G'day PNAI, Welcome to Linux.org
Which Linux (there 500 of them )
WHat is Caldera software....somehting from the 'net ?
I am unable to help you, but this information will likely be of use to those here who can.
Which Linux (there 500 of them )
WHat is Caldera software....somehting from the 'net ?
I am unable to help you, but this information will likely be of use to those here who can.
Caldera was a business oriented linux distro which was last released in about 2002. At the time it wasn't much of a choice in this neck of the woods which was dominated by Red Hat and debian.
The Latex-375 was a HP printer that came out in the early 1990s, though I think it was updated over the years.
It would be interesting to hear about the uses of these old technologies in today's context, and how useful they have still been.
The SIGSEGV error means "Invalid memory reference" (see man 7 signal). The error basically indicates that some process was trying to access memory that is outside of the boundaries in which it's supposed to function. To avoid messing up another process's memory space on the system, the offending process is stopped and that SIGSEGV signal is sent to the screen where standard output usually goes, with the error message.
If the distro and the printer worked before, and then suddenly didn't work, then it's hard to say what the problem is, whether it's software or hardware. One could re-install the software to see if it would work again, or one could check the hardware. It's not clear which tools would be best suited for such old hardware, but maybe the modern ones such as smartmontools and memtest86+ would work. They can be used from a live disk or rescue disk. Such a disk may need to be in CD form if usb is not available. Unsure if HP diagnostic tools can help.
Last edited:
Error messages are often sent to stderr instead of stdout.
Trying using journalctl -xe to check the system journal after your seg fault to see if it provides any useful information. Osprey is correct, for the most part.
On Linux systems, and others, virtual memory is divided up into pages and is segmented. When a process attempts to access a page of memory that has not been allocated to it it receives a seg fault signal. This commonly occurs when a null pointer is used instead of a valid memory address. One process cannot access another process' memory unless the kernel is broken. Each process receives a number of pages of memory from the kernel and those pages have virtual addresses. Other processes will receive their own pages of virtual memory with their own addresses. The kernel keeps track of which actual pages belong to which processes. When a process attempts to access virtual memory that is not found in one of the pages of virtual memory that the kernel has allocated to that process the kernel will send a seg fault signal to the process that attempts to access a virtual memory address that has not been assigned to the process. The virtual address is not at all likely to be the same as the actual memory address in physical RAM. The default signal handler for a seg fault signal will cause the process to produce an error and exit. This can be caught and processed by the process instead. See sigaction(2) for more information on that. The kill and stop signals cannot be caught for obvious reasons.
Signed,
Matthew Campbell
Trying using journalctl -xe to check the system journal after your seg fault to see if it provides any useful information. Osprey is correct, for the most part.
On Linux systems, and others, virtual memory is divided up into pages and is segmented. When a process attempts to access a page of memory that has not been allocated to it it receives a seg fault signal. This commonly occurs when a null pointer is used instead of a valid memory address. One process cannot access another process' memory unless the kernel is broken. Each process receives a number of pages of memory from the kernel and those pages have virtual addresses. Other processes will receive their own pages of virtual memory with their own addresses. The kernel keeps track of which actual pages belong to which processes. When a process attempts to access virtual memory that is not found in one of the pages of virtual memory that the kernel has allocated to that process the kernel will send a seg fault signal to the process that attempts to access a virtual memory address that has not been assigned to the process. The virtual address is not at all likely to be the same as the actual memory address in physical RAM. The default signal handler for a seg fault signal will cause the process to produce an error and exit. This can be caught and processed by the process instead. See sigaction(2) for more information on that. The kill and stop signals cannot be caught for obvious reasons.
Signed,
Matthew Campbell
Yes indeed @Trenix25 , the error message is sent to standard error by default. The usual state of affairs is that both standard output and standard error are both sent to the same terminal screen unless there's been some redirection applied to the code.
In relation to the systemd journal, it's very unlikely that a Caldera installation from around 2002 (if it was one of the latest releases) would be running systemd which was first introduced in about 2011 in fedora. The old style syslog messages may however be present, and they would certainly be worth inspection for any hints about the error other than the error message itself. Perhaps check the text files, if they exist, in
/var/log/syslog and /var/log/messages.
Often, unfortunately, there are no more details than the error itself, but what is listed as happening directly before the error may be of interest.
In relation to the systemd journal, it's very unlikely that a Caldera installation from around 2002 (if it was one of the latest releases) would be running systemd which was first introduced in about 2011 in fedora. The old style syslog messages may however be present, and they would certainly be worth inspection for any hints about the error other than the error message itself. Perhaps check the text files, if they exist, in
/var/log/syslog and /var/log/messages.
Often, unfortunately, there are no more details than the error itself, but what is listed as happening directly before the error may be of interest.
CaffeineAddict
Well-Known Member
SIGSEGV means segmentation fault, it's a type of program or driver error meaning that invalid portion of memory was accessed or written to by the program, ex. memory which was released by the program or not allocated and so it may not be used.It's not system error but it might be caused by regression, ex. outdated system, driver or library.
Yes, the SIGSEGV is a "segmentation fault" where a segment in memory which is an address of another segment of memory it is not entitled to in its code, is being "referenced", hence the expression "Invalid memory reference" as the definition of SIGSEGV. In other words, the offending program has attempted to read from or write to a prohibited area of memory by referring to that area it wants, which usually leads to the operating system terminating the program to prevent corruption in memory. The kernel tries to prevent the actual writing to the prohibited area, which may be successful. If successful in disallowing the memory violation, the machine won't crash, but only the program fails. If however, the bad code actually does access the prohibited memory despite the kernel's efforts to prevent it, then the machine is more likely to freeze, become unrecoverable and need a reboot.
Linux is a bit more stable than that. A seg fault shouldn't cause the kernel to crash. Linux has come a long way. I remember using SLS Linux at first back in the 90s and then Slackware. I also remember the horror stories about X86Free, or whatever it was called back then, setting computer monitors on fire when people tried to use an incompatible video resolution by overclocking their horizontal sync limit on their monitor. These days many computers use something other than a VGA port when connecting to their monitor. I used fvwm back then instead of KDE5.
You are making this sound like much more of a problem than it really is. The kernel allocates memory to a process in pages and when that process attempt to access an address that does not exist in one of those pages the kernel sends a seg fault signal to the process. The virtual memory addresses that one process uses have nothing to do with any virtual memory addresses used by any other Linux processes on the same computer. The kernel hasn't "protected" itself, the hardware, or any other processes running on the computer. The most common cause of a seg fault is when a process attempts to use a null pointer. It means the program is buggy and needs to be patched.
Linux uses at least three different kinds of virtual memory: text/code, data, and stack. Running /usr/bin/top will let you see how these are being used by some of the different process on the system.
Signed,
Matthew Campbell
I take your points @Trenix25 . No issues there. When you write "Linux has come a long way", this is certainly the case. I have been, however, mindful that the OP mentioned that he is running Caldera which was discontinued in about 2002, and we have no more details than that.
My post #7 was in large part about relating the language used in describing the problem given the language in the signal man page, "Invalid memory reference", and @CaffeineAddict 's reference to the term "segmentation fault". It was to hopefully allow the OP to understand the issue at that level rather than dive into the details of memory management. In relation to the kernel, the reference in post #7 at the end was to a system freeze occurring.
Unfortunately the OP hasn't yet returned with more details so it's not so easy to provide relevant assistance, but as mentioned in post #3, it's an interesting situation.
Last edited:
