--===============1678787279== Content-Type: multipart/signed; boundary="nextPart3089575.3vqFHj3tk0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3089575.3vqFHj3tk0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Lubos Lunak wrote: >> True. And I think all those "new" that allocate memory that is >> potentially large should either be in a try/catch block or use >> new(nothrow) so as to catch bad allocations. One such case is >> demarshalling a QDataStream. > >=A0That still may not actually help that much with memory overcommitting. That's a different problem. Memory overcommitting means the memory requested to be allocated was of a=20 reasonable size. And when you run out of memory after overcommitting, the=20 application gets a SIGBUS that's really difficult to understand. What I am suggesting is getting rid of unreasonable memory allocations.=20 There are many cases of backtraces in bugs.kde.org of applications=20 crashing after std::bad_alloc was thrown from the inside of=20 QString::setLength. =2D-=20 Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 2. T=F3 cennan his weorc gearu, ymbe se circolwyrde, wear=F0 se c=E6gbord a= nd se=20 leohtspeccabord, and =FEa m=FDs c=F3mon lator. On =FEone d=E6g, he hine res= te. --nextPart3089575.3vqFHj3tk0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBDluV3M/XwBW70U1gRAiELAKC7wsU8vnhHHGbfbxYwWHbpTR2B8wCdFKbK 2Hr3JDvOk0BT3FFtoGtcYeU= =Z9zk -----END PGP SIGNATURE----- --nextPart3089575.3vqFHj3tk0-- --===============1678787279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============1678787279==--