Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #3254 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-11 03:43 -0700 |
| Articles | 20 on this page of 241 — 42 participants |
Back to article view | Back to comp.lang.c
Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:37 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 02:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 04:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 11:58 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-06 03:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 00:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:18 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 02:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-05-05 15:40 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 21:17 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-05 18:45 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 10:16 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:28 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:34 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 13:03 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 14:32 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-07 16:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 16:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-08 06:19 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-08 17:18 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 09:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:34 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 10:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 15:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-12 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:01 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 12:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:15 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-08 15:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 09:32 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-08 10:46 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 21:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 09:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:24 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 15:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 15:15 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 19:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:26 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 21:06 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:27 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-05 20:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-06 02:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 19:27 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 19:54 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Marco Parrone <marco@marcoparrone.com> - 2011-05-06 17:32 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 21:46 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 00:28 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 06:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 22:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 01:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 09:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Willem <willem@toad.stack.nl> - 2011-05-08 10:44 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 07:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 13:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 07:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:38 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:44 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 21:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 13:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 14:19 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 10:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 19:04 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 11:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-09 23:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:06 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-10 00:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:17 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-10 07:10 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-10 13:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:48 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:54 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-12 05:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 00:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 23:21 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:08 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:48 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:03 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:23 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-12 09:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 06:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-12 14:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 22:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-10 21:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-11 02:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:42 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-15 00:23 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-14 22:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:19 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-16 08:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-16 21:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 09:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 10:20 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-17 15:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-17 20:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 16:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-17 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 01:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:29 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 04:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-17 16:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 17:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-23 21:57 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-23 21:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-24 11:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-24 10:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:11 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 16:22 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 21:25 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Seebs <usenet-nospam@seebs.net> - 2011-05-10 17:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 17:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 12:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 03:53 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:18 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 04:42 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 09:12 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-10 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 10:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 08:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-11 08:12 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 07:41 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-11 12:45 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 07:50 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-10 11:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 09:27 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 22:50 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:49 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 20:05 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-08 13:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:22 -0700
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-07 19:11 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-08 10:16 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-09 09:03 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 08:59 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 03:01 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:13 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 09:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:41 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 02:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:17 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 10:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:20 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 14:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 14:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 22:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:32 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 11:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 10:57 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Shao Miller <sha0.miller@gmail.com> - 2011-05-07 21:35 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 23:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 08:39 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 09:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 10:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-09 17:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-05-10 11:20 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-08 17:59 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-09 09:01 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 12:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:01 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-08 13:10 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 22:21 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-04 12:54 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-04 12:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-06-07 06:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-10 21:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 13:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 23:42 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 19:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 09:24 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:29 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-08 00:28 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 07:30 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 15:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:33 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-14 11:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-14 15:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-10 22:14 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:08 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:15 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
| From | ImpalerCore <jadill33@gmail.com> |
|---|---|
| Date | 2011-06-07 06:30 -0700 |
| Message-ID | <f4d0dcec-d6c6-4f84-9187-77ea7d3dba1e@17g2000prr.googlegroups.com> |
| In reply to | #5444 |
On Jun 4, 3:59 pm, Michael Press <rub...@pacbell.net> wrote: > In article <isd9up$hk...@news.xmission.com>, > gaze...@shell.xmission.com (Kenny McCormack) wrote: > > > In article <DHExp.72925$HX7.47...@news.usenetserver.com>, > > Scott Lurndal <sl...@pacbell.net> wrote: > > ... > > >yep. Kenny seems to be of the oft-stated opinion that the only > > >topic suitable for comp.lang.c is standard C (specifically discussions > > >of the standard itself, rather than using the langauge) and I'm not > > >sure that he is aware that for the most part, unix == linux from an > > >application development standpoint. > > > It ain't me, babe! > > > (sing the rest of this old Turtles tune to yourself...) > > They might have covered it, but it ain't theirs, babe. Bob Dylan, as are many of the classic remix hits like the Byrds "Mr. Tambourine Man", Hendrix "All Along the Watchtower", and others. The best use of Bob Dylan music is to annoy pop-culture teenager passengers while driving.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-10 21:56 -0700 |
| Message-ID | <rubrum-6D21F8.21561710062011@news.albasani.net> |
| In reply to | #5599 |
In article <f4d0dcec-d6c6-4f84-9187-77ea7d3dba1e@17g2000prr.googlegroups.com>, ImpalerCore <jadill33@gmail.com> wrote: > On Jun 4, 3:59 pm, Michael Press <rub...@pacbell.net> wrote: > > In article <isd9up$hk...@news.xmission.com>, > > gaze...@shell.xmission.com (Kenny McCormack) wrote: > > > > > In article <DHExp.72925$HX7.47...@news.usenetserver.com>, > > > Scott Lurndal <sl...@pacbell.net> wrote: > > > ... > > > >yep. Kenny seems to be of the oft-stated opinion that the only > > > >topic suitable for comp.lang.c is standard C (specifically discussions > > > >of the standard itself, rather than using the langauge) and I'm not > > > >sure that he is aware that for the most part, unix == linux from an > > > >application development standpoint. > > > > > It ain't me, babe! > > > > > (sing the rest of this old Turtles tune to yourself...) > > > > They might have covered it, but it ain't theirs, babe. > > Bob Dylan, as are many of the classic remix hits like the Byrds "Mr. > Tambourine Man", Hendrix "All Along the Watchtower", and others. The > best use of Bob Dylan music is to annoy pop-culture teenager > passengers while driving. "Don't put on any airs when you're down on Rue Morgue Avenue." -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-07 13:53 -0700 |
| Message-ID | <1a007b7a-ee46-4a6e-9293-79cfd1b4c61e@b19g2000yqg.googlegroups.com> |
| In reply to | #3446 |
On May 7, 9:41 pm, Nobody <nob...@nowhere.com> wrote: > On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote: > >> And instead you run out of heap. > > > Aye. But there's portable ways of checking that: malloc will just > > return NULL, which can be handled nicely and safely, instead of the > > system throwing a SIGSEGV. > > You forgot a case: malloc() succeeds but the process receives SIGKILL when > it actually tries to use the allocated memory (OOM-killer). > > This can be prevented by disabling overcommit, but on some systems the > cost of doing so is unacceptably high, i.e. you may need to provide ten > times (or worse) as much swap space as will ever be used in practice. Spot on. I hadn't thought of that one. <reads up on OOM-Killer> However, if i understand http://linux-mm.org/OOM_Killer correctly (interesting read, BTW), processes may be killed, but not with a SIGSEGV, so the program does not crash, but is terminated by the system. This may not be the desired outcome, but it's not a bug. And as K. Thompson points out, it may actually kill a different process, based on the result of badness() and the Law of Least Surprize. In any case, malloc should still return NULL if allocation fails, and the manpage says it does. That processes may be terminated by the system as a consequence of that call is another matter entirely.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-07 15:16 -0700 |
| Message-ID | <lnaaeyp35x.fsf@nuthaus.mib.org> |
| In reply to | #3449 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On May 7, 9:41 pm, Nobody <nob...@nowhere.com> wrote:
>> On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote:
>> >> And instead you run out of heap.
>>
>> > Aye. But there's portable ways of checking that: malloc will just
>> > return NULL, which can be handled nicely and safely, instead of the
>> > system throwing a SIGSEGV.
>>
>> You forgot a case: malloc() succeeds but the process receives SIGKILL when
>> it actually tries to use the allocated memory (OOM-killer).
>>
>> This can be prevented by disabling overcommit, but on some systems the
>> cost of doing so is unacceptably high, i.e. you may need to provide ten
>> times (or worse) as much swap space as will ever be used in practice.
>
> Spot on. I hadn't thought of that one.
>
> <reads up on OOM-Killer>
>
> However, if i understand http://linux-mm.org/OOM_Killer correctly
> (interesting read, BTW), processes may be killed, but not with a
> SIGSEGV, so the program does not crash, but is terminated by the
> system. This may not be the desired outcome, but it's not a bug.
>
> And as K. Thompson points out, it may actually kill a different
> process, based on the result of badness() and the Law of Least
> Surprize.
>
> In any case, malloc should still return NULL if allocation fails, and
> the manpage says it does. That processes may be terminated by the
> system as a consequence of that call is another matter entirely.
The problem, as I see it, is that by returning a non-null value, the
system promises the program that it can use the allocated memory.
Later invoking the OOM killer when the program actually tries to
use it seems to me to be a violation of that promise.
I understand that overly optimistic allocation can make sense
for stack space; a program will likely never use as much stack
as it could. But I'm not convinced that the same thing applies
to malloc(). If a program calls malloc(), it's telling the OS that
it *will* use that memory (and probably soon). If the system can't
fulfill the request, it should refuse it in the first place.
Do many actual programs malloc() much more memory than they're
actually going to use?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2011-05-07 23:42 +0100 |
| Message-ID | <yw1xoc3egmkk.fsf@unicorn.mansr.com> |
| In reply to | #3464 |
Keith Thompson <kst-u@mib.org> writes: > "Kleuskes & Moos" <kleuske@xs4all.nl> writes: >> On May 7, 9:41 pm, Nobody <nob...@nowhere.com> wrote: >>> On Sat, 07 May 2011 10:24:42 -0700, Kleuskes & Moos wrote: >>> >> And instead you run out of heap. >>> >>> > Aye. But there's portable ways of checking that: malloc will just >>> > return NULL, which can be handled nicely and safely, instead of the >>> > system throwing a SIGSEGV. >>> >>> You forgot a case: malloc() succeeds but the process receives SIGKILL when >>> it actually tries to use the allocated memory (OOM-killer). >>> >>> This can be prevented by disabling overcommit, but on some systems the >>> cost of doing so is unacceptably high, i.e. you may need to provide ten >>> times (or worse) as much swap space as will ever be used in practice. >> >> Spot on. I hadn't thought of that one. >> >> <reads up on OOM-Killer> >> >> However, if i understand http://linux-mm.org/OOM_Killer correctly >> (interesting read, BTW), processes may be killed, but not with a >> SIGSEGV, so the program does not crash, but is terminated by the >> system. This may not be the desired outcome, but it's not a bug. >> >> And as K. Thompson points out, it may actually kill a different >> process, based on the result of badness() and the Law of Least >> Surprize. >> >> In any case, malloc should still return NULL if allocation fails, and >> the manpage says it does. That processes may be terminated by the >> system as a consequence of that call is another matter entirely. > > The problem, as I see it, is that by returning a non-null value, the > system promises the program that it can use the allocated memory. > Later invoking the OOM killer when the program actually tries to > use it seems to me to be a violation of that promise. > > I understand that overly optimistic allocation can make sense > for stack space; a program will likely never use as much stack > as it could. But I'm not convinced that the same thing applies > to malloc(). If a program calls malloc(), it's telling the OS that > it *will* use that memory (and probably soon). If the system can't > fulfill the request, it should refuse it in the first place. > > Do many actual programs malloc() much more memory than they're > actually going to use? They do indeed, and that practice is the very reason for overcommit existing in the first place. -- Måns Rullgård mans@mansr.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-07 19:37 -0700 |
| Message-ID | <ln62plq5nk.fsf@nuthaus.mib.org> |
| In reply to | #3466 |
Måns Rullgård <mans@mansr.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> The problem, as I see it, is that by returning a non-null value, the
>> system promises the program that it can use the allocated memory.
>> Later invoking the OOM killer when the program actually tries to
>> use it seems to me to be a violation of that promise.
>>
>> I understand that overly optimistic allocation can make sense
>> for stack space; a program will likely never use as much stack
>> as it could. But I'm not convinced that the same thing applies
>> to malloc(). If a program calls malloc(), it's telling the OS that
>> it *will* use that memory (and probably soon). If the system can't
>> fulfill the request, it should refuse it in the first place.
>>
>> Do many actual programs malloc() much more memory than they're
>> actually going to use?
>
> They do indeed, and that practice is the very reason for overcommit
> existing in the first place.
(I'm keeping this in comp.unix.programmer and comp.lang.c for now, since
it still seems relevant to both. Feel free to set followups if that
changes.)
Why? If a program finds it needs more memory, it can always call
malloc() again, or realloc() to increase the size of an existing block.
Can you give an example where it makes sense to allocate a large block
of memory and not use it (or use only a small initial portion of it)?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-05-08 07:17 +0200 |
| Message-ID | <4dc6271d$0$38643$4fafbaef@reader1.news.tin.it> |
| In reply to | #3476 |
"Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio news:ln62plq5nk.fsf@nuthaus.mib.org... > Måns Rullgård <mans@mansr.com> writes: >> Keith Thompson <kst-u@mib.org> writes: > [...] >>> The problem, as I see it, is that by returning a non-null value, the >>> system promises the program that it can use the allocated memory. >>> Later invoking the OOM killer when the program actually tries to >>> use it seems to me to be a violation of that promise. >>> >>> I understand that overly optimistic allocation can make sense >>> for stack space; a program will likely never use as much stack >>> as it could. But I'm not convinced that the same thing applies >>> to malloc(). If a program calls malloc(), it's telling the OS that >>> it *will* use that memory (and probably soon). If the system can't >>> fulfill the request, it should refuse it in the first place. >>> >>> Do many actual programs malloc() much more memory than they're >>> actually going to use? >> >> They do indeed, and that practice is the very reason for overcommit >> existing in the first place. > > (I'm keeping this in comp.unix.programmer and comp.lang.c for now, since > it still seems relevant to both. Feel free to set followups if that > changes.) > > Why? If a program finds it needs more memory, it can always call > malloc() again, or realloc() to increase the size of an existing block. > Can you give an example where it makes sense to allocate a large block > of memory and not use it (or use only a small initial portion of it)? for to make the OS in trouble
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-05-08 09:24 +0200 |
| Message-ID | <4dc6450b$0$38649$4fafbaef@reader1.news.tin.it> |
| In reply to | #3484 |
"io_x" <a@b.c.invalid> ha scritto nel messaggio news:4dc6271d$0$38643$4fafbaef@reader1.news.tin.it... > > "Keith Thompson" <kst-u@mib.org> ha scritto nel messaggio > news:ln62plq5nk.fsf@nuthaus.mib.org... >> Måns Rullgård <mans@mansr.com> writes: >>> Keith Thompson <kst-u@mib.org> writes: >> [...] >>>> The problem, as I see it, is that by returning a non-null value, the >>>> system promises the program that it can use the allocated memory. >>>> Later invoking the OOM killer when the program actually tries to >>>> use it seems to me to be a violation of that promise. >>>> >>>> I understand that overly optimistic allocation can make sense >>>> for stack space; a program will likely never use as much stack >>>> as it could. But I'm not convinced that the same thing applies >>>> to malloc(). If a program calls malloc(), it's telling the OS that >>>> it *will* use that memory (and probably soon). If the system can't >>>> fulfill the request, it should refuse it in the first place. >>>> >>>> Do many actual programs malloc() much more memory than they're >>>> actually going to use? >>> >>> They do indeed, and that practice is the very reason for overcommit >>> existing in the first place. >> >> (I'm keeping this in comp.unix.programmer and comp.lang.c for now, since >> it still seems relevant to both. Feel free to set followups if that >> changes.) >> >> Why? If a program finds it needs more memory, it can always call >> malloc() again, or realloc() to increase the size of an existing block. >> Can you give an example where it makes sense to allocate a large block >> of memory and not use it (or use only a small initial portion of it)? > > for to make the OS in trouble for meke the prog in trouble becouse loose the controll
[toc] | [prev] | [next] | [standalone]
| From | Måns Rullgård <mans@mansr.com> |
|---|---|
| Date | 2011-05-08 10:36 +0100 |
| Message-ID | <yw1xfwoph6tk.fsf@unicorn.mansr.com> |
| In reply to | #3476 |
Keith Thompson <kst-u@mib.org> writes: > Måns Rullgård <mans@mansr.com> writes: >> Keith Thompson <kst-u@mib.org> writes: > [...] >>> The problem, as I see it, is that by returning a non-null value, the >>> system promises the program that it can use the allocated memory. >>> Later invoking the OOM killer when the program actually tries to >>> use it seems to me to be a violation of that promise. >>> >>> I understand that overly optimistic allocation can make sense >>> for stack space; a program will likely never use as much stack >>> as it could. But I'm not convinced that the same thing applies >>> to malloc(). If a program calls malloc(), it's telling the OS that >>> it *will* use that memory (and probably soon). If the system can't >>> fulfill the request, it should refuse it in the first place. >>> >>> Do many actual programs malloc() much more memory than they're >>> actually going to use? >> >> They do indeed, and that practice is the very reason for overcommit >> existing in the first place. > > (I'm keeping this in comp.unix.programmer and comp.lang.c for now, since > it still seems relevant to both. Feel free to set followups if that > changes.) > > Why? If a program finds it needs more memory, it can always call > malloc() again, or realloc() to increase the size of an existing block. > Can you give an example where it makes sense to allocate a large block > of memory and not use it (or use only a small initial portion of it)? It sometimes makes sense to allocate a large block and only use small scattered portions of it to simplify indexing. Using only a small _initial_ portion obviously never makes sense. -- Måns Rullgård mans@mansr.com
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-14 13:29 +0300 |
| Message-ID | <87ei41wp62.fsf@bazspaz.fatphil.org> |
| In reply to | #3513 |
Måns Rullgård <mans@mansr.com> writes: > Keith Thompson <kst-u@mib.org> writes: > > Måns Rullgård <mans@mansr.com> writes: > >> Keith Thompson <kst-u@mib.org> writes: > > [...] > >>> The problem, as I see it, is that by returning a non-null value, the > >>> system promises the program that it can use the allocated memory. > >>> Later invoking the OOM killer when the program actually tries to > >>> use it seems to me to be a violation of that promise. > >>> > >>> I understand that overly optimistic allocation can make sense > >>> for stack space; a program will likely never use as much stack > >>> as it could. But I'm not convinced that the same thing applies > >>> to malloc(). If a program calls malloc(), it's telling the OS that > >>> it *will* use that memory (and probably soon). If the system can't > >>> fulfill the request, it should refuse it in the first place. > >>> > >>> Do many actual programs malloc() much more memory than they're > >>> actually going to use? > >> > >> They do indeed, and that practice is the very reason for overcommit > >> existing in the first place. > > > > (I'm keeping this in comp.unix.programmer and comp.lang.c for now, since > > it still seems relevant to both. Feel free to set followups if that > > changes.) > > > > Why? If a program finds it needs more memory, it can always call > > malloc() again, or realloc() to increase the size of an existing block. > > Can you give an example where it makes sense to allocate a large block > > of memory and not use it (or use only a small initial portion of it)? > > It sometimes makes sense to allocate a large block and only use small > scattered portions of it to simplify indexing. Using only a small > _initial_ portion obviously never makes sense. Sparse use of memory often implies serious cache abuse (at all levels, it increases the likelyhood of swapping too, for example) and that should be avoided. To answer Keith, I think the true answer is that it's easier to just not think about it, and trust that the underlying operating system works around your unwillingness to think. Phil -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." -- Matthew Vernon
[toc] | [prev] | [next] | [standalone]
| From | Barry Margolin <barmar@alum.mit.edu> |
|---|---|
| Date | 2011-05-08 00:28 -0400 |
| Message-ID | <barmar-AF9DCB.00281508052011@62-183-169-81.bb.dnainternet.fi> |
| In reply to | #3464 |
In article <lnaaeyp35x.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: > Do many actual programs malloc() much more memory than they're > actually going to use? Probably not, but that's not relevant. malloc isn't the system call that adds memory to the process, sbrk is. When malloc find that the heap is used up, it probably DOES request more memory with sbrk than it needs just to satisfy the current request. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-07 23:06 -0700 |
| Message-ID | <8foh98-6c2.ln1@wilbur.25thandClement.com> |
| In reply to | #3481 |
In comp.unix.programmer Barry Margolin <barmar@alum.mit.edu> wrote: > In article <lnaaeyp35x.fsf@nuthaus.mib.org>, > Keith Thompson <kst-u@mib.org> wrote: > > Do many actual programs malloc() much more memory than they're > > actually going to use? > Probably not, but that's not relevant. malloc isn't the system call > that adds memory to the process, sbrk is. When malloc find that the > heap is used up, it probably DOES request more memory with sbrk than it > needs just to satisfy the current request. But not that much relative to overall system memory on the systems vanilla Linux tends to run on. We're talking a few megabytes per sbrk() or mmap() request, not gigabytes. And where system memory tends to be quite limited, as on embedded systems, the case for overcommit is even worse. This is why the iPhone didn't support multitasking originally; and why Android requires all applications to run effectively stateless, AFAIU. The best argument for overcommit involves fork(), but I don't think it's persuasive today, if it ever was persuasive. Memory hogs like databases don't fork+exec programs once up and running, so you're not sacrificing convenience or practicality by preventing a 1GB process from forking.
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-08 07:30 +0100 |
| Message-ID | <87wri1n1q4.fsf@temporary-address.org.uk> |
| In reply to | #3481 |
Barry Margolin <barmar@alum.mit.edu> writes: > In article <lnaaeyp35x.fsf@nuthaus.mib.org>, > Keith Thompson <kst-u@mib.org> wrote: > >> Do many actual programs malloc() much more memory than they're >> actually going to use? > > Probably not, but that's not relevant. malloc isn't the system call > that adds memory to the process, sbrk is. When malloc find that the > heap is used up, it probably DOES request more memory with sbrk than it > needs just to satisfy the current request. Ah! Like Keith I'd often wondered about just why this happens. That makes a lot of sense: malloc wants big chunks of memory to parcel out from. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-08 15:51 +0000 |
| Message-ID | <EZyxp.145417$Co6.25782@news.usenetserver.com> |
| In reply to | #3493 |
Dr Nick <3-nospam@temporary-address.org.uk> writes: >Barry Margolin <barmar@alum.mit.edu> writes: > >> In article <lnaaeyp35x.fsf@nuthaus.mib.org>, >> Keith Thompson <kst-u@mib.org> wrote: >> >>> Do many actual programs malloc() much more memory than they're >>> actually going to use? >> >> Probably not, but that's not relevant. malloc isn't the system call >> that adds memory to the process, sbrk is. When malloc find that the >> heap is used up, it probably DOES request more memory with sbrk than it >> needs just to satisfy the current request. > >Ah! Like Keith I'd often wondered about just why this happens. That >makes a lot of sense: malloc wants big chunks of memory to parcel out >from. And sbrk() needs to allocate full pages to the process, so at a minimum, a call to sbrk will fetch at least 4k bytes (on ia32/x86_64 - more on PPC/Sparc/MIPS/ia64 where the minimum page size could be considerably larger). scott
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-14 13:33 +0300 |
| Message-ID | <87aaepwoyx.fsf@bazspaz.fatphil.org> |
| In reply to | #3530 |
scott@slp53.sl.home (Scott Lurndal) writes: > Dr Nick <3-nospam@temporary-address.org.uk> writes: > >Barry Margolin <barmar@alum.mit.edu> writes: > > > >> In article <lnaaeyp35x.fsf@nuthaus.mib.org>, > >> Keith Thompson <kst-u@mib.org> wrote: > >> > >>> Do many actual programs malloc() much more memory than they're > >>> actually going to use? > >> > >> Probably not, but that's not relevant. malloc isn't the system call > >> that adds memory to the process, sbrk is. When malloc find that the > >> heap is used up, it probably DOES request more memory with sbrk than it > >> needs just to satisfy the current request. > > > >Ah! Like Keith I'd often wondered about just why this happens. That > >makes a lot of sense: malloc wants big chunks of memory to parcel out > >from. > > And sbrk() needs to allocate full pages to the process, so at a minimum, > a call to sbrk will fetch at least 4k bytes (on ia32/x86_64 - more on > PPC/Sparc/MIPS/ia64 where the minimum page size could be considerably larger). But if you are sbrking more because the page size is large, then you're not sbrking more than you need. None of the pages, all 1 of them, goes unmapped. There's no over-commit in this scenario. The question was about overcommit. Phil -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." -- Matthew Vernon
[toc] | [prev] | [next] | [standalone]
| From | Barry Margolin <barmar@alum.mit.edu> |
|---|---|
| Date | 2011-05-14 11:08 -0400 |
| Message-ID | <barmar-910AFC.11081314052011@news.eternal-september.org> |
| In reply to | #3939 |
In article <87aaepwoyx.fsf@bazspaz.fatphil.org>, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > > > Dr Nick <3-nospam@temporary-address.org.uk> writes: > > >Barry Margolin <barmar@alum.mit.edu> writes: > > > > > >> In article <lnaaeyp35x.fsf@nuthaus.mib.org>, > > >> Keith Thompson <kst-u@mib.org> wrote: > > >> > > >>> Do many actual programs malloc() much more memory than they're > > >>> actually going to use? > > >> > > >> Probably not, but that's not relevant. malloc isn't the system call > > >> that adds memory to the process, sbrk is. When malloc find that the > > >> heap is used up, it probably DOES request more memory with sbrk than it > > >> needs just to satisfy the current request. > > > > > >Ah! Like Keith I'd often wondered about just why this happens. That > > >makes a lot of sense: malloc wants big chunks of memory to parcel out > > >from. > > > > And sbrk() needs to allocate full pages to the process, so at a minimum, > > a call to sbrk will fetch at least 4k bytes (on ia32/x86_64 - more on > > PPC/Sparc/MIPS/ia64 where the minimum page size could be considerably > > larger). > > But if you are sbrking more because the page size is large, then you're > not sbrking more than you need. None of the pages, all 1 of them, goes > unmapped. There's no over-commit in this scenario. The question was about > overcommit. Do malloc() implementations typically only grow the heap by just one page at a time? My suspicion is that they grow by bigger chunks, to avoid frequent system calls to get more memory. Kind of like the programming strategy when you have a dynamically growing array, where you double its size every time it fills up. And I'll also bet that the initial heap size is over-committed, to avoid a flurry of sbrk() calls when the program starts and does lots of memory allocations. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-14 15:53 +0000 |
| Message-ID | <dAxzp.1114$9z6.168@news.usenetserver.com> |
| In reply to | #3956 |
Barry Margolin <barmar@alum.mit.edu> writes: >In article <87aaepwoyx.fsf@bazspaz.fatphil.org>, > Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote: > >> scott@slp53.sl.home (Scott Lurndal) writes: >> >> > Dr Nick <3-nospam@temporary-address.org.uk> writes: >> > >Barry Margolin <barmar@alum.mit.edu> writes: >> > > >> > >> In article <lnaaeyp35x.fsf@nuthaus.mib.org>, >> > >> Keith Thompson <kst-u@mib.org> wrote: >> > >> >> > >>> Do many actual programs malloc() much more memory than they're >> > >>> actually going to use? >> > >> >> > >> Probably not, but that's not relevant. malloc isn't the system call >> > >> that adds memory to the process, sbrk is. When malloc find that the >> > >> heap is used up, it probably DOES request more memory with sbrk than it >> > >> needs just to satisfy the current request. >> > > >> > >Ah! Like Keith I'd often wondered about just why this happens. That >> > >makes a lot of sense: malloc wants big chunks of memory to parcel out >> > >from. >> > >> > And sbrk() needs to allocate full pages to the process, so at a minimum, >> > a call to sbrk will fetch at least 4k bytes (on ia32/x86_64 - more on >> > PPC/Sparc/MIPS/ia64 where the minimum page size could be considerably >> > larger). >> >> But if you are sbrking more because the page size is large, then you're >> not sbrking more than you need. None of the pages, all 1 of them, goes >> unmapped. There's no over-commit in this scenario. The question was about >> overcommit. > >Do malloc() implementations typically only grow the heap by just one >page at a time? My suspicion is that they grow by bigger chunks, to >avoid frequent system calls to get more memory. Kind of like the >programming strategy when you have a dynamically growing array, where >you double its size every time it fills up. > >And I'll also bet that the initial heap size is over-committed, to avoid >a flurry of sbrk() calls when the program starts and does lots of memory >allocations. Linux, first two brk's in a large application. Looks like 0x21000 bytes were allocated by the first brk call (135,168 bytes). brk(0) = 0x1862000 brk(0x1883000) = 0x1883000 scott
[toc] | [prev] | [next] | [standalone]
| From | Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> |
|---|---|
| Date | 2011-05-10 22:14 +0100 |
| Message-ID | <IU.D20110510.T211523.P4460.Q0@J.de.Boyne.Pollard.localhost> |
| In reply to | #3493 |
>> malloc isn't the system call that adds memory to the process, sbrk >> is. [...] >> > Ah! Like Keith I'd often wondered about just why this happens. That > makes a lot of sense: malloc wants big chunks of memory to parcel out > from. > Yes. malloc() and free() are almost always just library functions, that are layered on top of the operating system's actual memory allocator. The operating system memory allocator varies quite widely. M. Margolin mentioned sbrk() for simplicity, but nowadays that model, which doesn't really match up very conveniently with the process address spaces that one gets in these days of dynamically loaded libraries, multiple threads, and so forth, is commonly relegated. Nowadays, a common implementation is to suballocate from within usually sparsely committed (i.e. the address space is reserved but not all pages are committed) heaps, usually in the MiBs, created on demand via VirtualAlloc(), mmap(), DosAllocMem(), or whatever mechanism the operating system provides. Operating system memory allocators usually work in terms of whole pages; and again a common implementation is to commit and decommit one or more pages, within the sparse page range used for a heap, as appropriate as memory is malloc()ed and free()d.
[toc] | [prev] | [next] | [standalone]
| From | Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> |
|---|---|
| Date | 2011-05-08 11:08 +0000 |
| Message-ID | <4dc6799d$0$81481$e4fe514c@news.xs4all.nl> |
| In reply to | #3464 |
Keith Thompson <kst-u@mib.org> writes: >I understand that overly optimistic allocation can make sense >for stack space; a program will likely never use as much stack >as it could. But I'm not convinced that the same thing applies >to malloc(). If a program calls malloc(), it's telling the OS that >it *will* use that memory (and probably soon). If the system can't >fulfill the request, it should refuse it in the first place. There are many usage of anonymous memory in a system: stack, heap but also the copy-on-write pages after a fork(). The system may not allocate the different types of memory in a different way, but some make a difference between the stack (no reservation is made) or fork/malloc (a reservation is made). Specifically in the case of fork, there is an argument to be made that that memory is unlikely ever used. >Do many actual programs malloc() much more memory than they're >actually going to use? Not a lot; but a lot of fork()ing happens without ever touching the copy-on-write pages. That is likely the most important reason for overcommit. Casper --
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-08 08:15 +0100 |
| Message-ID | <pan.2011.05.08.07.14.56.906000@nowhere.com> |
| In reply to | #3449 |
On Sat, 07 May 2011 13:53:41 -0700, Kleuskes & Moos wrote: > However, if i understand http://linux-mm.org/OOM_Killer correctly > (interesting read, BTW), processes may be killed, but not with a > SIGSEGV, so the program does not crash, but is terminated by the > system. This may not be the desired outcome, but it's not a bug. It's effectively sent SIGKILL, which cannot be caught, rather than SIGSEGV, which can be caught. SIGSEGV isn't really the same thing as a crash (largely because "crash" isn't a clearly-defined concept). I normally consider a crash to be when the process' data gets corrupted resulting in the process going out of control (which usually ends when it receives SIGSEGV due to dereferencing a bogus pointer).
[toc] | [prev] | [next] | [standalone]
Page 12 of 13 — ← Prev page 1 … 10 11 [12] 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web