Segmentation fault should raise an exception?

[Hrushikesh Tilak]

Hi,

I am working on an elgamal encryptor. The following is part of my
code. This was using "g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2)"


Dec is of type ElGamalDecryptor;
encryptedMessage, decryptedMessage are strings.

StringSource(encryptedMessage , true , new
HexDecoder(Dec.CreateDecryptionFilter(rng , new
StringSink(decryptedMessage))));

results in an segmentation fault when encryptedMessage is set to "a",
but works properly when it is feeded with a valid
elgamal-encrypted-and-then-hexencoded message. Shouldn't an exception
be caught somewhere in this chain of Filters?

The following is the backtrace from gdb:

#0 0xb7dd0cb5 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0x080af075 in CryptoPP::ArraySink::Put2 (this=0xbfc3cceb,
begin=0x0, length=1, messageEnd=0, blocking=true) at filters.cpp:513
#2 0x08061526 in CryptoPP::BufferedTransformation::ChannelPut2
(this=0xbfc3cc64, channel=@0x81648a0, begin=0x0, length=1,
messageEnd=0, blocking=false)
at cryptlib.cpp:250
#3 0x080af1f1 in CryptoPP::StringStore::CopyRangeTo2
(this=0xbfc3cd10, target=@0xbfc3cc64, begin=@0xbfc3cc80, end=1,
channel=@0x81648a0, blocking=true)
at filters.cpp:948
#4 0x080633b8 in CryptoPP::BufferedTransformation::Peek
(this=0xbfc3cd10, outString=0xbfc3cceb "", peekMax=1) at
cryptlib.h:867
#5 0x08060466 in CryptoPP::BufferedTransformation::Peek
(this=0xbfc3cd10, outByte=@0xbfc3cceb) at cryptlib.cpp:322
#6 0x080d9a21 in CryptoPP::Integer::Decode (this=0xbfc3ce04,
bt=@0xbfc3cd10, inputLen=256, s=CryptoPP::Integer::UNSIGNED) at
integer.cpp:3080
#7 0x080ddecf in CryptoPP::Integer::Decode (this=0xbfc3ce04,
input=0x0, inputLen=256, s=CryptoPP::Integer::UNSIGNED) at
integer.cpp:3072
#8 0x080dfd92 in Integer (this=0xbfc3ce04, encodedInteger=0x0,
byteCount=256, s=CryptoPP::Integer::UNSIGNED) at integer.cpp:2833
#9 0x080bdf00 in
CryptoPP::DL_GroupParameters_IntegerBased::DecodeElement
(this=0xbfc3d164, encoded=0x0, checkForGroupMembership=true) at
gfpcrypt.cpp:193
#10 0x0804fbe8 in
CryptoPP::DL_DecryptorBase<CryptoPP::Integer>::Decrypt
(this=0xbfc3d124, rng=@0xbfc3d280, ciphertext=0x0, ciphertextLength=0,
plaintext=0x0, parameters=@0x81648a4) at /usr/include/cryptopp/
pubkey.h:1194
#11 0x08065031 in CryptoPP::PK_DefaultDecryptionFilter::Put2
(this=0x8169588, inString=0x81687e0 "�", length=0, messageEnd=-2,
blocking=true)
at cryptlib.cpp:626
#12 0x080ae550 in CryptoPP::Filter::Output (this=0x8169628,
outputSite=2, inString=0x81687e0 "�", length=0, messageEnd=-1,
blocking=true,
channel=@0x81648a0) at filters.cpp:115
#13 0x0805e579 in CryptoPP::BaseN_Decoder::Put2 (this=0x8169628,
begin=0x0, length=0, messageEnd=-1, blocking=true) at basecode.cpp:163
#14 0x08061526 in CryptoPP::BufferedTransformation::ChannelPut2
(this=0x8169628, channel=@0x81648a0, begin=0x0, length=0,
messageEnd=-1, blocking=false)
at cryptlib.cpp:250
#15 0x08060667 in
CryptoPP::BufferedTransformation::TransferMessagesTo2
(this=0xbfc3d24c, target=@0x8169628, messageCount=@0xbfc3cff4,
channel=@0x81648a0,
blocking=true) at cryptlib.h:938
#16 0x080607ce in CryptoPP::BufferedTransformation::TransferAllTo2
(this=0xbfc3d24c, target=@0x8169628, channel=@0x81648a0,
blocking=true)
at cryptlib.cpp:448
#17 0x08052169 in
CryptoPP::SourceTemplate<CryptoPP::StringStore>::PumpAll2
(this=0xbfc3d234, blocking=true) at
/usr/include/cryptopp/filters.h:718
#18 0x0804b2f2 in CryptoPP::Source::PumpAll (this=0xbfc3d234) at
/usr/include/cryptopp/filters.h:689
#19 0x0804b32a in CryptoPP::Source::SourceInitialize (this=0xbfc3d234,
pumpAll=true, parameters=@0xbfc3d084) at
/usr/include/cryptopp/filters.h:700
#20 0x08059873 in StringSource (this=0xbfc3d234, string=@0xbfc3d270,
pumpAll=true, attachment=0x8169628) at
/usr/include/cryptopp/filters.h:744
#21 0x0804ac7f in main () at decrypt_using_elgamal.cpp:16

[Tim Lovell-Smith]

If the filter caught the exception, what should it do with it?
The filter doesn't know how to recover from the segmentation fault.
Perhaps you really want a different exception to be thrown - earlier -
when it detects the buffer length you passed it is too short?

On Dec 13, 4:09 pm, Hrushikesh Tilak <hrushikesh.ti...@gmail.com>
wrote:

[Hrushikesh Tilak]

On Dec 14, 8:49 am, Tim Lovell-Smith <Parchan...@gmail.com> wrote:
> If the filter caught the exception, what should it do with it?
> The filter doesn't know how to recover from the segmentation fault.
> Perhaps you really want a different exception to be thrown - earlier -
> when it detects the buffer length you passed it is too short?
>

My code does have a try-catch-block. What I meant was: No exception is
generated at all, when it should be.

[Tim Lovell-Smith]

Oh. I'm a little puzzled about why it is that way, but from a google
search it seems like segmentation fault does not normally raise an
exception.
See this discussion (hope the link works) entitled "Re: segmentation
fault exception handling"

http://www.velocityreviews.com/forums/t267889-re-segmentation-fault-exception-handling.html

To summarize the points of the discussion which sound relevant,

1) there is another way to catch segmentation fault (with signal
handler) dating from C
2) someone is of the opinion it should be up to user C++ code to
detect the problem (buffer size) and raise the exception. I agree,
because segmentation fault is non-determinstic - it might fail to
trigger, if you are in a valid memory page. Comparing buffer sizes is
deterministic.

Another point that I don't think they made clear in their discussion
that even if a segmentation fault occurs, in the case of writing to
memory, you could write some stuff to valid memory pages, which works,
then segfault occurs. You know you've done something stupid - but
since it was an accident to write to that memory, and raising an
exception doesn't undo those writes to memory that succeeded, you have
no idea what the consequences are going to be.

Hope this helps -
T

On Dec 14, 7:03 pm, Hrushikesh Tilak <hrushikesh.ti...@gmail.com>
wrote: