Is it possible to use try...except to catch SIGSEGV?

Thanks!

Once upon a time, Xiangrong Fang said:

Is it possible to use try...except to catch SIGSEGV?

I don't know if it is possible, but how about using fpSignal()? See http://www.freepascal.org/docs-html/rtl/baseunix/fpsignal.html

The document said it is "deprecated"? Also, I want this to be cross platform, not for unix only. The use case is:

try
  buf := GetMemory(1024);
  size := 10240;
  stream.Read(buf^, size);
except
  ??
end;

2013/3/14 Ewald

The documentation proposes the alternative too (however that is still platform specific indeed).

What about trying it yourself?

{$MODE OBJFPC}
var
 P: PChar;
begin
 try
  WriteLn (P^);
 except
  WriteLn (0);
 end;
end.

D:\TEMP>ppc386 -Mobjfpc t.pas
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Win32 for i386
Compiling t.pas
t.pas(5,12) Warning: Variable "P" does not seem to be initialized Linking t.exe
9 lines compiled, 0.5 sec , 26704 bytes code, 1644 bytes data 1 warning(s) issued

D:\TEMP>t.exe
0

Tomas

Is it possible to use try...except to catch SIGSEGV?

yes. The exception class is EAccessViolation.

Mattias

I am sorry that was what I thought, but does not work, see screenshot attached.

My environment:

~ $ uname -a
Linux fxrlm 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:51:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
~ $ cat /etc/lsb-release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=14
DISTRIB_CODENAME=nadia
DISTRIB_DESCRIPTION="Linux Mint 14 Nadia"
~ $

2013/3/14 Mattias Gaertner

That use case is a textbook example of why you should never try to catch and handle access violations, except possibly if you then warn the user that anything could happen if he continues (including erasing all files on his hard drive, if he's very unlucky).

An access violation often indicates that memory has been corrupted. Catching the access violation does not undo the memory corruption, it just informs you about this fact. If you continue after catching the exception in the above program, you will be working with corrupted memory, which means that the behaviour of your program becomes completely unpredictable afterwards.

Jonas

The screenshot does not show where exactly the problem happens (except for the address, but that is useless without context), i.e. if it is covered by the try..except construct. Try with the simple test I posted to see if it works or not.

In any case, Jonas is obviously right that you shouldn't try to catch SIGSEGV in such complex code (trying to catch the signal potentially happening in the middle of some nested processing which might leave the environment in completely undefined state).

Tomas

Indeed, it probably crashes in FreeMemory or fs.free because the heap manager structures have been corrupted. The fs.Read itself does not necessarily raise an exception by itself in case there's still enough room in the heap block that contains buf, or if another one comes right after it.

Jonas

@Xiangrong

In fact (after I saw the screenshot, that indeed the alloc mem is less than the read), there is a possibility that the above good does NOT even crash. Yet it corrupts memory and the app will crash at a random later point.

If the 1024 bytes happen to be allocated in such way that they are followed by other already alocated memory, then they can be accessed without SigSegV.

Thanks for the explanation. Now I see why my program some time crashed at gtk2*.inc...

2013/3/14 Martin