Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #306 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-05 12:18 -0700 |
| Articles | 20 on this page of 270 — 46 participants |
Back to article view | Back to comp.unix.programmer
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? Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-05 13:40 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 13:52 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 09:22 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 14:41 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 10:30 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 18:55 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 11:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-06 14:36 +0200
RLIMIT_STACK (was: Avoiding recursive stack overflow in C on Unix/Linux?) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-10 14:19 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 08:28 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 16:18 +0000
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 18:37 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 19:53 +0000
Re: RLIMIT_STACK Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-11 17:43 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:03 +0200
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:20 +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? Noob <root@127.0.0.1> - 2011-06-01 15:19 +0200
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? Michael Press <rubrum@pacbell.net> - 2011-05-07 21:02 -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? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:29 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-06 03:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 06:33 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 12:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 04:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 13:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 21:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:46 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-08 05:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Golden California Girls <gldncagrls@aol.com.mil> - 2011-05-07 08:59 -0700
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? Nicolas George <nicolas$george@salle-s.org> - 2011-05-11 21:07 +0000
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? "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-05-15 18:21 +0200
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? Nicolas George <nicolas$george@salle-s.org> - 2011-05-16 16:58 +0000
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? Michael Press <rubrum@pacbell.net> - 2011-05-07 23:27 -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? 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? Nobody <nobody@nowhere.com> - 2011-05-08 08:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:13 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:46 -0700
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? boltar2003@boltar.world - 2011-05-10 08:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 12:18 -0700
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2011-05-11 17:43 +0100 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <4vqq98-idq.ln1@leafnode-msgid.gclare.org.uk> |
| In reply to | #500 |
Xavier Roche wrote: > On 05/10/2011 03:19 PM, Geoff Clare wrote: >> How did you determine the initial thread's stack size? Did you >> actually grow the stack to that size? If not, you may find that >> it cannot grow beyond the RLIMIT_STACK limit, despite it appearing >> to have more space available. > > > First thread: (-DIN_FIRST_THREAD) > ------------ > > stack limit (rlim_cur): 8388608 bytes > stack hard limit (rlim_max): 4294967295 bytes > executing function > Caught SEGV > approx. final stack size: 10482351 > > "Second" thread: > --------------- > > stack limit (rlim_cur): 8388608 bytes > stack hard limit (rlim_max): 4294967295 bytes > executing function > Caught SEGV > approx. final stack size: 8384167 > > > Code sample: (adapted from my previous one) > ------------ [code snipped] I tried your program on two different Linux systems, one running Debian lenny with kernel 2.6.26, and the other running Debian squeeze with kernel 2.6.32, and they both produced the expected output when compiled with -DIN_FIRST_THREAD, i.e. the approx. final stack size reported was a little less than the rlim_cur value. If you are using a more recent kernel it's possible that a bug has been introduced at some point since 2.6.32. I also updated the "second thread" code to use pthread_attr_setstack() to set different stack sizes for the created thread (I tried 4MB and 16MB), and verified that the program reported an approx. final stack size of just under the new value, even though the rlim_cur value was still reported as 8MB. -- Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-11 20:03 +0200 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <iqej21$hr5$2@news.httrack.net> |
| In reply to | #536 |
Le 11/05/2011 18:43, Geoff Clare a écrit : > I tried your program on two different Linux systems, one running Debian > lenny with kernel 2.6.26, and the other running Debian squeeze with > kernel 2.6.32, and they both produced the expected output Tested on a 2.6.35-27 (amd64) ; but also reproduced on a 2.6.18 -- there must be something wrong in the environment (?) ulimit -s shows "8192" too, but the estimated stacksize if strangely near 10MB (10481815 ~= 10485760) And with 'ulimit -s 16384', the estimated size is.. strangely near 18MB. It seems that I always have 2MB more free space than limited -- maybe a special offer for the first thread ? :)
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-11 20:20 +0200 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <iqek26$hr5$3@news.httrack.net> |
| In reply to | #537 |
Le 11/05/2011 20:03, Xavier Roche a écrit : > It seems that I always have 2MB more free space than limited -- maybe a > special offer for the first thread ? :) Darn, this is it: the "special offer" is an infamous EXEC_STACK_BIAS patch (http://people.redhat.com/mingo/exec-shield/exec-shield-nx-2.6.19.patch) apparently used by RedHat. There is no way to detect this "bias", and therefore no way to detect the final guard page of the first thread on these systems :(
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2011-05-06 03:27 +0100 |
| Message-ID | <pan.2011.05.06.02.27.39.62000@nowhere.com> |
| In reply to | #309 |
On Thu, 05 May 2011 11:58:32 +0200, Xavier Roche wrote: > There is no portable way to find the stack bottom/size ; I am not even > sure what getrlimit(RLIMIT_STACK) returns exactly (current thread stack > size ? main thread stack size ? default stack size ?) It's the size of the region of address space allocated to the main thread's stack. > (And there is no portable way to find the stack top/bottom -- you'll > have to play with an address on the current stack around main, and play > with arithmetics with the page size) If available, the value returned by alloca() will typically be the exact bottom of the stack. alloca() doesn't conform to any standard, but it's a common extension.
[toc] | [prev] | [next] | [standalone]
| From | "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-05-06 00:03 -0700 |
| Message-ID | <08a67a2d-9947-4b8d-b4f6-802540dfdfff@e21g2000vbz.googlegroups.com> |
| In reply to | #329 |
On May 5, 9:27 pm, Nobody <nob...@nowhere.com> wrote: > On Thu, 05 May 2011 11:58:32 +0200, Xavier Roche wrote: > > There is no portable way to find the stack bottom/size ; I am not even > > sure what getrlimit(RLIMIT_STACK) returns exactly (current thread stack > > size ? main thread stack size ? default stack size ?) > > It's the size of the region of address space allocated to the main > thread's stack. > > > (And there is no portable way to find the stack top/bottom -- you'll > > have to play with an address on the current stack around main, and play > > with arithmetics with the page size) > > If available, the value returned by alloca() will typically be the exact > bottom of the stack. > > alloca() doesn't conform to any standard, but it's a common extension. The more conventional terminology would have alloca() returning something near the *top* of the stack - and the direction of stack growth is irrelevant. But so will taking the address of an automatic, which is much simpler. The approximate bottom of the stack could be stored at entry to main().
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-06 09:18 +0000 |
| Message-ID | <iq0edj$4nk$1@speranza.aioe.org> |
| In reply to | #331 |
On Fri, 6 May 2011 00:03:14 -0700 (PDT) "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> wrote: >> If available, the value returned by alloca() will typically be the exact >> bottom of the stack. >> >> alloca() doesn't conform to any standard, but it's a common extension. > > >The more conventional terminology would have alloca() returning >something near the *top* of the stack - and the direction of stack >growth is irrelevant. But so will taking the address of an automatic, >which is much simpler. The approximate bottom of the stack could be >stored at entry to main(). I'd not heard of that function before. Calling it with zero - alloca(0) - seems to work and return an address but the man page doesn't hint at whether this should work or work in the future. Would it be best to call it with a non zero value just in case the implementation changes? B2003
[toc] | [prev] | [next] | [standalone]
| From | "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-05-06 02:56 -0700 |
| Message-ID | <20c018a7-4700-4a07-a678-3fbef2869f8e@l30g2000vbn.googlegroups.com> |
| In reply to | #335 |
On May 6, 4:18 am, boltar2...@boltar.world wrote:
> On Fri, 6 May 2011 00:03:14 -0700 (PDT)
>
> "robertwess...@yahoo.com" <robertwess...@yahoo.com> wrote:
> >> If available, the value returned by alloca() will typically be the exact
> >> bottom of the stack.
>
> >> alloca() doesn't conform to any standard, but it's a common extension.
>
> >The more conventional terminology would have alloca() returning
> >something near the *top* of the stack - and the direction of stack
> >growth is irrelevant. But so will taking the address of an automatic,
> >which is much simpler. The approximate bottom of the stack could be
> >stored at entry to main().
>
> I'd not heard of that function before. Calling it with zero - alloca(0) -
> seems to work and return an address but the man page doesn't hint at
> whether this should work or work in the future. Would it be best to call it
> with a non zero value just in case the implementation changes?
While still non-portable, just write a function like:
char *getappxroximatestackpointer()
{
char c;
return &c;
}
Call it once at the beginning of main(), and save that value. Call it
again when you're interested, subtract the two (watch the order of the
subtraction based on the direction of stack growth - or do an abs() ),
and you'll have a pretty close measurement of the amount of stack
space you're current using on many implementations.
As I said, non-portable (not least, the stack doesn't have to be
contiguous storage), but it will work on many implementations.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-06-01 15:19 +0200 |
| Message-ID | <is5e8l$qdn$1@speranza.aioe.org> |
| In reply to | #340 |
robertwessel wrote:
> While still non-portable, just write a function like:
>
> char *getappxroximatestackpointer()
> {
> char c;
> return &c;
> }
>
> Call it once at the beginning of main(), and save that value. Call it
> again when you're interested, subtract the two (watch the order of the
> subtraction based on the direction of stack growth - or do an abs() ),
> and you'll have a pretty close measurement of the amount of stack
> space you're current using on many implementations.
>
> As I said, non-portable (not least, the stack doesn't have to be
> contiguous storage), but it will work on many implementations.
I think the biggest problem will be getting this past
optimizing compilers. The best bet is to write a small
function in assembly language, and link that.
On x86, something along the lines of
getappxroximatestackpointer:
mov %esp, %eax
ret
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-05 12:24 -0700 |
| Message-ID | <ce8a87e8-fffa-4287-84ee-271f0766c304@24g2000yqk.googlegroups.com> |
| In reply to | #306 |
On May 5, 11:37 am, boltar2...@boltar.world wrote: > Hello > > If a program recurses too deeply there's always a chance that it could > run out of stack space and die with a SIGSEGV. Is there any API that can > tell you how much stack space is left or some other method to prevent this > in C/C++? I realise I could catch the signal but thats a pretty damn ugly > way to do it. > > B2003 The only proper way to avoid stack-overflows is to prevent it from happening in the first place. If at all possible (and frequently it is) avoid recursion, if it's unavoidable, as it sometimes is, make sure your design prevents those situations from arising in the first place. Trying to solve a design problem by imposing artificial limitations seems a bad idea.
[toc] | [prev] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2011-05-05 15:40 -0400 |
| Message-ID | <44oc3hkkbp.fsf@lowell-desk.lan> |
| In reply to | #321 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > On May 5, 11:37 am, boltar2...@boltar.world wrote: >> Hello >> >> If a program recurses too deeply there's always a chance that it could >> run out of stack space and die with a SIGSEGV. Is there any API that can >> tell you how much stack space is left or some other method to prevent this >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly >> way to do it. >> >> B2003 > > The only proper way to avoid stack-overflows is to prevent it from > happening in the first place. If at all possible (and frequently it > is) avoid recursion, if it's unavoidable, as it sometimes is, make > sure your design prevents those situations from arising in the first > place. > > Trying to solve a design problem by imposing artificial limitations > seems a bad idea. Without in any way disagreeing, I can't imagine being able to come up with a contextual definition for "artificial" in that sentence. -- Lowell Gilbert, embedded/networking software engineer http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 02:18 -0700 |
| Message-ID | <e3823b09-0ee6-45d7-babf-b4320c06bac9@n10g2000yqf.googlegroups.com> |
| In reply to | #323 |
On 5 mei, 21:40, Lowell Gilbert <lguse...@be-well.ilk.org> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > > > > > > > > > On May 5, 11:37 am, boltar2...@boltar.world wrote: > >> Hello > > >> If a program recurses too deeply there's always a chance that it could > >> run out of stack space and die with a SIGSEGV. Is there any API that can > >> tell you how much stack space is left or some other method to prevent this > >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > >> way to do it. > > >> B2003 > > > The only proper way to avoid stack-overflows is to prevent it from > > happening in the first place. If at all possible (and frequently it > > is) avoid recursion, if it's unavoidable, as it sometimes is, make > > sure your design prevents those situations from arising in the first > > place. > > > Trying to solve a design problem by imposing artificial limitations > > seems a bad idea. > > Without in any way disagreeing, I can't imagine being able to come up > with a contextual definition for "artificial" in that sentence. Not inherent to the problem being solved or not part of the original, abstract, algorithm being implemented. But you're right, "artificial" is a weird word to use in the programming context.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-05-05 21:17 +0100 |
| Message-ID | <0.2a1dbd8ed34f263bf779.20110505211709BST.8739ks52d6.fsf@bsb.me.uk> |
| In reply to | #321 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > On May 5, 11:37 am, boltar2...@boltar.world wrote: >> If a program recurses too deeply there's always a chance that it could >> run out of stack space and die with a SIGSEGV. Is there any API that can >> tell you how much stack space is left or some other method to prevent this >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly >> way to do it. > > The only proper way to avoid stack-overflows is to prevent it from > happening in the first place. If at all possible (and frequently it > is) avoid recursion, if it's unavoidable, as it sometimes is, make > sure your design prevents those situations from arising in the first > place. I find this answer interesting, mainly because I think is suggests a very different view about programming. I would not try to avoid recursion "if at all possible". In general I consider that it is up to the system to provide the resources needed by a program and this includes stack for a reasonable amount of recursion. These resources can run out of course, and the stack is special in that few languages provide any way to handle its exhaustion elegantly, but that does not seem enough reason to design out all recursion. There are special cases: some environments are severely resource limited but there's no indication that the OP is using such a system and, anyway, I don't think you can make general rules from specific situations. > Trying to solve a design problem by imposing artificial limitations > seems a bad idea. Isn't this what you are doing? Isn't the ban on recursion not an artificial limitation? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Datesfat Chicks <datesfat.chicks@gmail.com> |
|---|---|
| Date | 2011-05-05 18:45 -0400 |
| Message-ID | <qs96s6hq5j01omk9fe73ijjg22j0pm5mrr@4ax.com> |
| In reply to | #325 |
On Thu, 05 May 2011 21:17:09 +0100, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > >> On May 5, 11:37 am, boltar2...@boltar.world wrote: >>> If a program recurses too deeply there's always a chance that it could >>> run out of stack space and die with a SIGSEGV. Is there any API that can >>> tell you how much stack space is left or some other method to prevent this >>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly >>> way to do it. >> >> The only proper way to avoid stack-overflows is to prevent it from >> happening in the first place. If at all possible (and frequently it >> is) avoid recursion, if it's unavoidable, as it sometimes is, make >> sure your design prevents those situations from arising in the first >> place. > >I find this answer interesting, mainly because I think is suggests a >very different view about programming. I would not try to avoid >recursion "if at all possible". In general I consider that it is up to >the system to provide the resources needed by a program and this >includes stack for a reasonable amount of recursion. These resources >can run out of course, and the stack is special in that few languages >provide any way to handle its exhaustion elegantly, but that does not >seem enough reason to design out all recursion. > >There are special cases: some environments are severely resource limited >but there's no indication that the OP is using such a system and, >anyway, I don't think you can make general rules from specific situations. > >> Trying to solve a design problem by imposing artificial limitations >> seems a bad idea. > >Isn't this what you are doing? Isn't the ban on recursion not an >artificial limitation? The restrictions on stack depth are no different than the restrictions on memory size or disk space that are present on any computer system. These limits have been relaxed over time, and certainly programs will run today on a typical computer that would not have run 10 years ago on a typical computer. "Don't use recursion" seems to be logically the same as "don't declare very large arrays" or "don't create really big files". It is dependent on the technology of the day, rather than being an absolute standard. These days I have a few files on my server that are on the order of 20G. That would have been unthinkable 10 years ago. DFC
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 02:44 -0700 |
| Message-ID | <cd74530d-3fcb-4a6a-8cc8-e173bf97f65a@n10g2000yqf.googlegroups.com> |
| In reply to | #326 |
On 6 mei, 00:45, Datesfat Chicks <datesfat.chi...@gmail.com> wrote: > On Thu, 05 May 2011 21:17:09 +0100, Ben Bacarisse > > > > > > > > > > <ben.use...@bsb.me.uk> wrote: > >"Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > >> On May 5, 11:37 am, boltar2...@boltar.world wrote: > >>> If a program recurses too deeply there's always a chance that it could > >>> run out of stack space and die with a SIGSEGV. Is there any API that can > >>> tell you how much stack space is left or some other method to prevent this > >>> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > >>> way to do it. > > >> The only proper way to avoid stack-overflows is to prevent it from > >> happening in the first place. If at all possible (and frequently it > >> is) avoid recursion, if it's unavoidable, as it sometimes is, make > >> sure your design prevents those situations from arising in the first > >> place. > > >I find this answer interesting, mainly because I think is suggests a > >very different view about programming. I would not try to avoid > >recursion "if at all possible". In general I consider that it is up to > >the system to provide the resources needed by a program and this > >includes stack for a reasonable amount of recursion. These resources > >can run out of course, and the stack is special in that few languages > >provide any way to handle its exhaustion elegantly, but that does not > >seem enough reason to design out all recursion. > > >There are special cases: some environments are severely resource limited > >but there's no indication that the OP is using such a system and, > >anyway, I don't think you can make general rules from specific situations. > > >> Trying to solve a design problem by imposing artificial limitations > >> seems a bad idea. > > >Isn't this what you are doing? Isn't the ban on recursion not an > >artificial limitation? > > The restrictions on stack depth are no different than the restrictions > on memory size or disk space that are present on any computer system. > > These limits have been relaxed over time, and certainly programs will > run today on a typical computer that would not have run 10 years ago > on a typical computer. > > "Don't use recursion" seems to be logically the same as "don't declare > very large arrays" or "don't create really big files". It is > dependent on the technology of the day, rather than being an absolute > standard. > > These days I have a few files on my server that are on the order of > 20G. That would have been unthinkable 10 years ago. Ah yes... Computers today are so fast and so big that sound design is superfluous. Unless of course you are dealing with huge amounts of data, since not only have memory sizes and processor speeds increased, the amount of data they are supposed to work on have also increased dramatically, thus cancelling out said improvements in size and speed. If you don't believe me, try importing planet.osm (see http://wiki.openstreetmap.org/wiki/Planet.osm) 25 years ago i never imagined i would fill a 54 Gb partition (20 Mb was a pretty big HD those days), now i'm using a 1Tb drive and looking at options for an 10 Tb Raid-server.
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-06 09:58 +0000 |
| Message-ID | <iq0goj$ait$1@speranza.aioe.org> |
| In reply to | #339 |
I implemented a simple program that would check when it was getting near
the limit of the stack but for some reason Linux sends it SEGV when
(assuming my program is correct) there should be 10 or 20K of space left
on the stack. Is this normal? I include the code below for someone to point
out the stupid mistake I must have made somewhere. I changed all void * to
char * just in case that was throwing the maths but it made no difference:
#include <stdio.h>
#include <stdlib.h>
#include <alloca.h>
#include <sys/time.h>
#include <sys/resource.h>
char *stack_top;
unsigned int depth;
void recurse()
{
unsigned long int dist;
++depth;
dist = labs((long int)(stack_top - (char *)&dist));
if (dist < 20000)
{
printf("Nearing limit: depth = %u, addr = %lu, dist to end = %lu
\n",
depth,&dist,dist);
}
recurse();
}
int main()
{
struct rlimit rl;
long int mult;
char *top;
depth = 0;
/* Find out which way stack is growing */
top = (char *)alloca(0);
stack_top = (char *)alloca(1);
if (stack_top < top)
{
puts("Stack grows downwards");
mult = -1;
}
else
{
puts("Stack grows upwards");
mult = 1;
}
/* Now find where max extent of the stack by getting its max size */
if (getrlimit(RLIMIT_STACK,&rl) == -1)
{
perror("getrlimit()");
return 1;
}
stack_top += (rl.rlim_cur * mult);
printf("Stack max size = %lu\n",rl.rlim_cur);
printf("Stack max extent = %lu\n",stack_top);
getchar();
recurse();
return 0;
}
B2003
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2011-05-06 11:11 +0100 |
| Message-ID | <87tyd82l5x.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #341 |
boltar2003@boltar.world writes: > I implemented a simple program that would check when it was getting near > the limit of the stack but for some reason Linux sends it SEGV when > (assuming my program is correct) there should be 10 or 20K of space left > on the stack. Is this normal? I include the code below for someone to point > out the stupid mistake I must have made somewhere. I changed all void * to > char * just in case that was throwing the maths but it made no difference: You're not taking into account the stack space above the call to main(), which will include some amount of space used by Libc plus the command line and environment. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-06 10:16 +0000 |
| Message-ID | <iq0hqp$db6$1@speranza.aioe.org> |
| In reply to | #345 |
On Fri, 06 May 2011 11:11:38 +0100 Richard Kettlewell <rjk@greenend.org.uk> wrote: >boltar2003@boltar.world writes: > >> I implemented a simple program that would check when it was getting near >> the limit of the stack but for some reason Linux sends it SEGV when >> (assuming my program is correct) there should be 10 or 20K of space left >> on the stack. Is this normal? I include the code below for someone to point >> out the stupid mistake I must have made somewhere. I changed all void * to >> char * just in case that was throwing the maths but it made no difference: > >You're not taking into account the stack space above the call to main(), >which will include some amount of space used by Libc plus the command >line and environment. Ah yes, of course. Doh! Would there be any way to find out how much space they take up or alternatively a way to find the starting base address of the stack when the process was first exec'd? B2003
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2011-05-06 11:28 +0100 |
| Message-ID | <87oc3g2kei.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #346 |
boltar2003@boltar.world writes: > Richard Kettlewell <rjk@greenend.org.uk> wrote: >> boltar2003@boltar.world writes: >>> I implemented a simple program that would check when it was getting >>> near the limit of the stack but for some reason Linux sends it SEGV >>> when (assuming my program is correct) there should be 10 or 20K of >>> space left on the stack. Is this normal? I include the code below >>> for someone to point out the stupid mistake I must have made >>> somewhere. I changed all void * to char * just in case that was >>> throwing the maths but it made no difference: >> >> You're not taking into account the stack space above the call to >> main(), which will include some amount of space used by Libc plus the >> command line and environment. > > Ah yes, of course. Doh! > > Would there be any way to find out how much space they take up or alternatively > a way to find the starting base address of the stack when the process was > first exec'd? You could extend the stack down (or up as the case may be) until you get a segfault and round the last good address to the page size. Not very efficient though. If you have access to the process's memory map you may be able to identify the stack (e.g. /proc/self/maps on Linux, possibly analogous interfaces on other platforms). Split stack tricks like the gcc feature mentioned earlier will probably betray you whatever you do... -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-06 02:34 -0700 |
| Message-ID | <3bd2f399-754b-40dc-90da-b2ee35184281@k25g2000yqf.googlegroups.com> |
| In reply to | #325 |
On 5 mei, 22:17, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > On May 5, 11:37 am, boltar2...@boltar.world wrote: > >> If a program recurses too deeply there's always a chance that it could > >> run out of stack space and die with a SIGSEGV. Is there any API that can > >> tell you how much stack space is left or some other method to prevent this > >> in C/C++? I realise I could catch the signal but thats a pretty damn ugly > >> way to do it. > > > The only proper way to avoid stack-overflows is to prevent it from > > happening in the first place. If at all possible (and frequently it > > is) avoid recursion, if it's unavoidable, as it sometimes is, make > > sure your design prevents those situations from arising in the first > > place. > > I find this answer interesting, mainly because I think is suggests a > very different view about programming. I would not try to avoid > recursion "if at all possible". In general I consider that it is up to > the system to provide the resources needed by a program and this > includes stack for a reasonable amount of recursion. These resources > can run out of course, and the stack is special in that few languages > provide any way to handle its exhaustion elegantly, but that does not > seem enough reason to design out all recursion. If you compare recursive to equivalent non-recursive algorithms, i think you will find recursion is usually slower and demands (much) more resources. So as a rule of thumb, don't recurse, unless you have to. And yes, i do have a background in embedded systems, where these considerations are more important than on modern PC's. > There are special cases: some environments are severely resource limited > but there's no indication that the OP is using such a system and, > anyway, I don't think you can make general rules from specific situations. well... It's bread and butter for the science guys and the practice is called "inference". Nevertheless, it's easy to show that recursive algorithms are outperformed my equivalent non-recursive ones. The saving grace of recursion is that recursive implementations are usually easier to understand. If it weren't for that, i'd ban the practice outright. > > Trying to solve a design problem by imposing artificial limitations > > seems a bad idea. > > Isn't this what you are doing? Isn't the ban on recursion not an > artificial limitation? Nope. It follows from the design of processors and a wish to avoid unneccesary overhead (passing arguments, stack-frame maintenance, pushing and popping return adresses) and that's without even considering any effect a call may have on things like branch- prediction, instruction pipe-lines and such. A 'call' instruction is (relative to a branch) quite expensive and prevents some optimisations like loop-unrolling. So no, that's not an artificial limitation, but a design consideration.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-06 15:09 -0700 |
| Message-ID | <rubrum-55B22D.15093606052011@news.albasani.net> |
| In reply to | #338 |
In article <3bd2f399-754b-40dc-90da-b2ee35184281@k25g2000yqf.googlegroups.com>, "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > The saving grace of recursion is that recursive implementations are > usually easier to understand. If it weren't for that, i'd ban the > practice outright. First it's recursive functions, then world domination. You are on a slippery slope. -- Michael Press
[toc] | [prev] | [next] | [standalone]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web