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 1 of 14 [1] 2 3 … 14 Next page →
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-05 09:37 +0000 |
| Subject | Avoiding recursive stack overflow in C on Unix/Linux? |
| Message-ID | <iptr5l$tkb$1@speranza.aioe.org> |
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
[toc] | [next] | [standalone]
| From | China Blue Veins <chine.bleu@yahoo.com> |
|---|---|
| Date | 2011-05-05 02:51 -0700 |
| Message-ID | <chine.bleu-D66A2B.02513505052011@62-183-169-81.bb.dnainternet.fi> |
| In reply to | #306 |
In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@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 On some systems there is setrlimit which can be used to set the stack size. On unix you can start with 'man -k limit' and examine individual man pages. -- Damn the living - It's a lovely life. I'm whoever you want me to be. Silver silverware - Where is the love? At least I can stay in character. Oval swimming pool - Where is the love? Annoying Usenet one post at a time. Damn the living - It's a lovely life. Why does Harmony have blue veins?
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-05 09:58 +0000 |
| Message-ID | <iptsbq$t3$1@speranza.aioe.org> |
| In reply to | #307 |
On Thu, 05 May 2011 02:51:35 -0700 China Blue Veins <chine.bleu@yahoo.com> wrote: >In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@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 > >On some systems there is setrlimit which can be used to set the stack size. On >unix you can start with 'man -k limit' and examine individual man pages. Actually I suppose i could use getrlimit to get the stack size but is there a clean way of actually finding the current position of top of the stack? I could take the addresses of local variables but that seems a bit prone to error. B2003
[toc] | [prev] | [next] | [standalone]
| From | China Blue Veins <chine.bleu@yahoo.com> |
|---|---|
| Date | 2011-05-05 04:47 -0700 |
| Message-ID | <chine.bleu-1E59F7.04474205052011@62-183-169-81.bb.dnainternet.fi> |
| In reply to | #308 |
In article <iptsbq$t3$1@speranza.aioe.org>, boltar2003@boltar.world wrote: > On Thu, 05 May 2011 02:51:35 -0700 > China Blue Veins <chine.bleu@yahoo.com> wrote: > >In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@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 > > > >On some systems there is setrlimit which can be used to set the stack size. > >On > >unix you can start with 'man -k limit' and examine individual man pages. > > Actually I suppose i could use getrlimit to get the stack size but is there > a clean way of actually finding the current position of top of the stack? I > could take the addresses of local variables but that seems a bit prone to > error. If you can decipher the code, the Boehm garbage collector/allocator can get the entire stack for a variety of systems. -- Damn the living - It's a lovely life. I'm whoever you want me to be. Silver silverware - Where is the love? At least I can stay in character. Oval swimming pool - Where is the love? Annoying Usenet one post at a time. Damn the living - It's a lovely life. Why does Harmony have blue veins?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-07 23:22 +0000 |
| Message-ID | <Iukxp.201858$fQ3.92313@news.usenetserver.com> |
| In reply to | #308 |
boltar2003@boltar.world writes:
>On Thu, 05 May 2011 02:51:35 -0700
>China Blue Veins <chine.bleu@yahoo.com> wrote:
>>In article <iptr5l$tkb$1@speranza.aioe.org>, boltar2003@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
>>
>>On some systems there is setrlimit which can be used to set the stack size. On
>>unix you can start with 'man -k limit' and examine individual man pages.
>
>Actually I suppose i could use getrlimit to get the stack size but is there
>a clean way of actually finding the current position of top of the stack? I
>could take the addresses of local variables but that seems a bit prone to
>error.
Why would it be prone to error? It may be off by a couple of bytes, depending
on how many automatics (and alloca() calls) before you take the address. There
is no other portable way. (When I've written debuggers, I've used the following
non-portable function with G++ - lose the static keyword for GCC):
#define ALWAYS_INLINE inline __attribute__((always_inline))
static ALWAYS_INLINE uintptr_t
get_rsp()
{
uintptr_t rsp;
__asm__ __volatile__ ("movq %%rsp, %0": "=r" (rsp));
return rsp;
}
in 32-bit mode:
__asm__ __volatile__ ("movl %%esp, %0": "=r" (rsp));
You can also use __builtin_frame_address (see info gcc).
scott
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-05 11:58 +0200 |
| Message-ID | <iptsc8$83f$2@news.httrack.net> |
| In reply to | #306 |
On 05/05/2011 11:37 AM, boltar2003@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. 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 ?) (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)
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2011-05-05 13:40 +0100 |
| Message-ID | <1eia98-ftk.ln1@leafnode-msgid.gclare.org.uk> |
| In reply to | #309 |
Xavier Roche wrote:
> On 05/05/2011 11:37 AM, boltar2003@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.
>
> 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 ?)
Here is what the POSIX/SUS standard says about RLIMIT_STACK:
This is the maximum size of the initial thread's stack, in bytes.
The implementation does not automatically grow the stack beyond
this limit. If this limit is exceeded, SIGSEGV shall be generated
for the thread. If the thread is blocking SIGSEGV, or the process
is ignoring or catching SIGSEGV and has not made arrangements to
use an alternate stack, the disposition of SIGSEGV shall be set to
SIG_DFL before it is generated.
So it is just for the initial thread (which I assume is what you meant
by "main thread"). Created threads each have their own stack size
which can be set in the thread attributes.
If the OP is contemplating catching the SIGSEGV he should take note of
the part about using an alternate stack (for the catching function).
--
Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-05 13:52 +0000 |
| Message-ID | <ipua3a$50f$1@speranza.aioe.org> |
| In reply to | #312 |
On Thu, 5 May 2011 13:40:01 +0100 >If the OP is contemplating catching the SIGSEGV he should take note of >the part about using an alternate stack (for the catching function). I don't really understand what it means by an alternate stack. Could someone clarify its purpose? B2003
[toc] | [prev] | [next] | [standalone]
| From | Azazel <azazel@remove.azazel.net> |
|---|---|
| Date | 2011-05-05 09:22 -0500 |
| Message-ID | <slrnis5cci.ttg.azazel@pnakotis.dreamlands> |
| In reply to | #313 |
On 2011-05-05, boltar2003@boltar.world <boltar2003@boltar.world> wrote: > On Thu, 5 May 2011 13:40:01 +0100 >>If the OP is contemplating catching the SIGSEGV he should take note of >>the part about using an alternate stack (for the catching function). > > I don't really understand what it means by an alternate stack. Could > someone clarify its purpose? It is possible to define an alternative stack for signal-handling. Read the sigaltstack man-page. -- Az.
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-05 14:41 +0000 |
| Message-ID | <ipucvm$cjc$1@speranza.aioe.org> |
| In reply to | #314 |
On Thu, 05 May 2011 09:22:40 -0500 Azazel <azazel@remove.azazel.net> wrote: >On 2011-05-05, boltar2003@boltar.world <boltar2003@boltar.world> wrote: >> On Thu, 5 May 2011 13:40:01 +0100 >>>If the OP is contemplating catching the SIGSEGV he should take note of >>>the part about using an alternate stack (for the catching function). >> >> I don't really understand what it means by an alternate stack. Could >> someone clarify its purpose? > >It is possible to define an alternative stack for signal-handling. Read >the sigaltstack man-page. I understand what it does, but I don't understand why? Whats the benefit of having an alternate stack? How does it affect signal handling? B2003
[toc] | [prev] | [next] | [standalone]
| From | Azazel <azazel@remove.azazel.net> |
|---|---|
| Date | 2011-05-05 10:30 -0500 |
| Message-ID | <slrnis5gaq.ttg.azazel@pnakotis.dreamlands> |
| In reply to | #315 |
On 2011-05-05, boltar2003@boltar.world wrote: > On Thu, 05 May 2011 09:22:40 -0500 Azazel wrote: > > On 2011-05-05, boltar2003@boltar.world wrote: > > > On Thu, 5 May 2011 13:40:01 +0100 > > > > If the OP is contemplating catching the SIGSEGV he should take > > > > note of the part about using an alternate stack (for the > > > > catching function). > > > > > > I don't really understand what it means by an alternate stack. > > > Could someone clarify its purpose? > > > > It is possible to define an alternative stack for signal-handling. > > Read the sigaltstack man-page. > > I understand what it does, but I don't understand why? Whats the > benefit of having an alternate stack? How does it affect signal > handling? From the notes in the Linux man-page: The most common usage of an alternate signal stack is to handle the SIGSEGV signal that is generated if the space available for the normal process stack is exhausted: in this case, a signal handler for SIGSEGV cannot be invoked on the process stack; if we wish to handle it, we must use an alternate signal stack. Establishing an alternate signal stack is useful if a process expects that it may exhaust its standard stack. This may occur, for example, because the stack grows so large that it encounters the upwardly growing heap, or it reaches a limit established by a call to setrlimit(RLIMIT_STACK, &rlim). If the standard stack is exhausted, the kernel sends the process a SIGSEGV sig- nal. In these circumstances the only way to catch this signal is on an alternate signal stack. -- Az.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-07 23:23 +0000 |
| Message-ID | <Hvkxp.201859$fQ3.146813@news.usenetserver.com> |
| In reply to | #315 |
boltar2003@boltar.world writes: >On Thu, 05 May 2011 09:22:40 -0500 >Azazel <azazel@remove.azazel.net> wrote: >>On 2011-05-05, boltar2003@boltar.world <boltar2003@boltar.world> wrote: >>> On Thu, 5 May 2011 13:40:01 +0100 >>>>If the OP is contemplating catching the SIGSEGV he should take note of >>>>the part about using an alternate stack (for the catching function). >>> >>> I don't really understand what it means by an alternate stack. Could >>> someone clarify its purpose? >> >>It is possible to define an alternative stack for signal-handling. Read >>the sigaltstack man-page. > >I understand what it does, but I don't understand why? Whats the benefit >of having an alternate stack? How does it affect signal handling? > >B2003 > If you blow your main stack, the kernel can't push the activation record for the signal handler on it. If you have an alternate signal stack, the kernel will push the AR on it instead. scott
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-05 18:55 +0200 |
| Message-ID | <ipukqk$tgd$1@news.httrack.net> |
| In reply to | #314 |
Le 05/05/2011 16:22, Azazel a écrit : > It is possible to define an alternative stack for signal-handling. Read > the sigaltstack man-page. Note that, on Linux, the ucontext_t will contain the alternate stack info in this case. If you want to detect stack overflows, you'd better take note of the stack bottom/size before (in a thread variable, for example -- even if this is strictly speaking unsafe as pthread_* functions are not signal-safe ; at least as per POSIX)
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2011-05-05 11:58 -0700 |
| Message-ID | <sj8b98-bqc.ln1@wilbur.25thandClement.com> |
| In reply to | #317 |
Xavier Roche <xroche@free.fr.nospam.invalid> wrote: > Le 05/05/2011 16:22, Azazel a ?crit : > > It is possible to define an alternative stack for signal-handling. Read > > the sigaltstack man-page. > Note that, on Linux, the ucontext_t will contain the alternate stack > info in this case. If you want to detect stack overflows, you'd better > take note of the stack bottom/size before (in a thread variable, for > example -- even if this is strictly speaking unsafe as pthread_* > functions are not signal-safe ; at least as per POSIX) Or smuggle that info in the alternate stack, say in a block preceding an aligned address you pass to sigaltstack. AFAIU, sigaltstack sets an alternative stack per thread, so you can store information about the faulting thread in its alternate stack. Just use MINSIGSTKSZ to figure out the minimum modulus you'd need to be able to calculate the previous block from executing code which does pointer arithmetic on an automatic storage object. Simply using page sizes should probably work, too.
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-06 14:36 +0200 |
| Message-ID | <iq0q11$83f$4@news.httrack.net> |
| In reply to | #312 |
On 05/05/2011 02:40 PM, Geoff Clare wrote: > Here is what the POSIX/SUS standard says about RLIMIT_STACK: > > So it is just for the initial thread (which I assume is what you meant > by "main thread"). Created threads each have their own stack size > which can be set in the thread attributes. Humm, after playing with it, it seems on Linux that it is the default thread stack size. The first thread size is much greater that the vzlue returned by getrlimit(RLIMIT_STACK).
[toc] | [prev] | [next] | [standalone]
| From | Geoff Clare <geoff@clare.See-My-Signature.invalid> |
|---|---|
| Date | 2011-05-10 14:19 +0100 |
| Subject | RLIMIT_STACK (was: Avoiding recursive stack overflow in C on Unix/Linux?) |
| Message-ID | <fjqn98-klh.ln1@leafnode-msgid.gclare.org.uk> |
| In reply to | #352 |
Xavier Roche wrote: > On 05/05/2011 02:40 PM, Geoff Clare wrote: >> Here is what the POSIX/SUS standard says about RLIMIT_STACK: >> >> So it is just for the initial thread (which I assume is what you meant >> by "main thread"). Created threads each have their own stack size >> which can be set in the thread attributes. > > Humm, after playing with it, it seems on Linux that it is the default > thread stack size. The first thread size is much greater that the vzlue > returned by getrlimit(RLIMIT_STACK). 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. (If it can actually grow beyond the RLIMIT_STACK limit, then that's a non-conformance.) -- Geoff Clare <netnews@gclare.org.uk>
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-11 08:28 +0200 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <iqdaac$bu7$1@news.httrack.net> |
| In reply to | #479 |
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)
------------
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <signal.h>
#include <setjmp.h>
#include <sys/ucontext.h>
#include <assert.h>
#include <sys/time.h>
#include <sys/resource.h>
#ifndef IN_FIRST_THREAD
#include <pthread.h>
#endif
static sigjmp_buf jmp_return;
static void *stack_addr = NULL;
static void handler(int code, siginfo_t *si, void *ctx) {
static const char message[] = "Caught SEGV\n";
(void) write(2, message, sizeof(message) - 1);
/* take note of the address */
stack_addr = si->si_addr;
/* and return to context */
siglongjmp(jmp_return, 1);
}
/* Crappy recusrive function. */
static long recurse(long i) {
if (i > 3) {
return recurse(i - 1)*recurse(i - 2)*recurse(i - 3);
} else {
return 1;
}
}
static void *myFun(void *arg) {
char approx_base = 42;
struct sigaction sa;
struct rlimit rlStack;
/* Install alternative stack. */
stack_t * const ss = calloc(1, sizeof(stack_t));
ss->ss_size = SIGSTKSZ;
ss->ss_sp = malloc(ss->ss_size);
ss->ss_flags = 0;
if (sigaltstack(ss, NULL) == -1) {
assert(0);
}
/* Install SEGV handler. */
if (sigemptyset(&sa.sa_mask) != 0) {
abort();
}
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO | SA_ONSTACK;
if (sigaction(SIGSEGV, &sa, NULL) != 0) {
abort();
}
/* Print stack size */
if (getrlimit(RLIMIT_STACK, &rlStack) == 0) {
printf("stack limit (rlim_cur): %u bytes\n", (int) rlStack.rlim_cur);
printf("stack hard limit (rlim_max): %u bytes\n", (int)
rlStack.rlim_max);
}
/* Save context. */
printf("executing function\n");
if (sigsetjmp(jmp_return, 1) == 0) {
const long result = recurse(100000000);
printf("oops, I got a result (%lu)\n", result);
} else {
const uintptr_t offs = (uintptr_t) &approx_base - (uintptr_t)
stack_addr;
fprintf(stderr, "approx. final stack size: %lu\n",
(long) offs);
}
return NULL;
}
int main(int argc, char **argv) {
#ifdef IN_FIRST_THREAD
/* First thread */
(void) myFun(NULL);
#else
/* Another thread */
pthread_t t;
if (pthread_create(&t, NULL, myFun, NULL) == 0) {
if (pthread_join(t, NULL) == 0) {
printf("success\n");
return EXIT_SUCCESS;
}
}
return EXIT_FAILURE;
#endif
return EXIT_SUCCESS;
}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-11 16:18 +0000 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <%Eyyp.12738$GM6.1659@news.usenetserver.com> |
| In reply to | #500 |
Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes: >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 I don't believe that stacks for pthreads actually autogrow. The main stack is in a particular region of the address space which is known to the kernel, and the kernel will automatically grow that stack; but the kernel has no knowlege of the fact that the memory allocated for the stack for subsequently created threads is actually stack; particularly when the pthreads implementation is done in a library. I suppose the library could install a signal handler for SIGSEGV and SIGBUS and extend the stack on those, but that would interfere with process use of the same signals. Now, when linux uses clone() to create threads, all bets are off. And note that RLIM_MAX is the theoretical maximum. If there isn't enough memory and swapspace, your actual limit may be less. scott
[toc] | [prev] | [next] | [standalone]
| From | Xavier Roche <xroche@free.fr.NOSPAM.invalid> |
|---|---|
| Date | 2011-05-11 18:37 +0200 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <iqee0g$hr5$1@news.httrack.net> |
| In reply to | #534 |
Le 11/05/2011 18:18, Scott Lurndal a écrit : > I don't believe that stacks for pthreads actually autogrow. Experience shows that pthread stacks have a fixed size, which seems to be, by default, the RLIMIT_STACK softlimit. > And note that RLIM_MAX is the theoretical maximum. It appears to be UINT_MAX
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2011-05-11 19:53 +0000 |
| Subject | Re: RLIMIT_STACK |
| Message-ID | <ePByp.2$n%6.1@news.usenetserver.com> |
| In reply to | #535 |
Xavier Roche <xroche@free.fr.NOSPAM.invalid> writes: >Le 11/05/2011 18:18, Scott Lurndal a écrit : >> I don't believe that stacks for pthreads actually autogrow. > >Experience shows that pthread stacks have a fixed size, which seems to >be, by default, the RLIMIT_STACK softlimit. > >> And note that RLIM_MAX is the theoretical maximum. > >It appears to be UINT_MAX RLIM_MAX is usually set to an initial value when the kernel boots for the init process (pid == 1). It may be RLIM_INFINITY. Since all processes inherit from init, unless a process (or the login shell) change it max value, it will be equal to the boot time default. RLIM_INFINITY is usually set to the largest representable value that will fit in an rlim_t (32-bit or 64-bit). scott
[toc] | [prev] | [next] | [standalone]
Page 1 of 14 [1] 2 3 … 14 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web