Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #71186 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-09-25 04:02 +0200 |
| Last post | 2015-10-02 00:16 +0200 |
| Articles | 20 on this page of 332 — 34 participants |
Back to article view | Back to comp.lang.c
Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 04:02 +0200
Re: Unexpected and difficult to understand SIGSEGV "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-09-24 19:51 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
Re: Unexpected and difficult to understand SIGSEGV John Gordon <gordon@panix.com> - 2015-09-25 04:32 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:09 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 22:07 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-25 18:46 -0400
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 10:57 +1200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-25 21:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-26 16:51 +1200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 10:45 +0100
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 03:39 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-26 12:20 +0100
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-26 06:39 -0700
Re: Unexpected and difficult to understand SIGSEGV fir <profesor.fir@gmail.com> - 2015-09-27 01:45 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-26 23:11 +0200
Re: Unexpected and difficult to understand SIGSEGV jacobnavia <jacob@jacob.remcomp.fr> - 2015-09-25 10:28 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 10:33 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:05 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-25 16:44 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:08 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 10:55 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-25 14:00 +0200
Re: Unexpected and difficult to understand SIGSEGV luser droog <luser.droog@gmail.com> - 2015-09-25 09:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-25 20:25 +0100
Re: Unexpected and difficult to understand SIGSEGV <william@wilbur.25thandClement.com> - 2015-09-25 19:07 -0700
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-26 10:47 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-26 10:34 -0400
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-26 15:28 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 17:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-27 09:59 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 02:52 -0700
Re: Unexpected and difficult to understand SIGSEGV Noob <root@127.0.0.1> - 2015-09-30 20:13 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:17 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-30 04:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:34 +1300
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:05 +0000
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-02 08:25 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:02 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 12:57 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-06 09:23 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-07 11:18 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:52 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 09:51 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 11:07 +0000
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 15:09 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 07:34 +0000
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 10:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:14 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-30 12:26 +0200
Re: Unexpected and difficult to understand SIGSEGV Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-30 11:58 +0100
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:16 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:21 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-01 19:27 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 07:58 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:52 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 16:10 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-27 11:15 +0100
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 08:47 +0000
Re: Unexpected and difficult to understand SIGSEGV Andrew Cooper <amc96@cam.ac.uk> - 2015-09-26 00:02 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 00:02 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-26 23:32 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 22:10 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 17:01 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-27 22:15 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:36 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 10:40 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 23:58 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:08 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:25 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:50 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:06 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:15 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:20 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:24 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:44 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:50 +1300
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-09-27 23:44 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 20:17 +1300
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 01:06 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 16:59 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 09:23 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:47 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 13:46 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-29 07:52 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:15 +0200
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:55 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-02 11:59 -0400
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-03 11:51 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 15:25 -0400
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:50 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-09-27 18:32 -0400
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:37 -0700
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 17:50 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-28 18:18 +0000
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-28 11:31 -0700
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 07:37 +0000
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:38 -0700
Re: Unexpected and difficult to understand SIGSEGV asetofsymbols@gmail.com - 2015-09-27 17:39 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:42 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:46 +0200
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 09:56 +0000
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 18:20 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 15:54 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 18:23 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 00:33 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 11:42 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:04 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:32 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:37 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 16:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:21 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:30 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-28 00:41 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 01:52 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 12:59 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-28 17:07 +0200
Re: Unexpected and difficult to understand SIGSEGV Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-30 11:17 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-30 06:08 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-27 17:09 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 02:17 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-28 09:00 -0700
Re: Unexpected and difficult to understand SIGSEGV ais523 <ais523@nethack4.org> - 2015-10-01 14:05 +0000
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 16:23 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 10:26 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 16:53 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 11:26 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-01 21:57 +0200
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 13:30 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 13:57 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 17:19 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-01 15:38 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 17:14 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:19 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 15:01 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 18:26 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 18:37 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-04 19:13 -0400
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 17:57 -0700
Re: Unexpected and difficult to understand SIGSEGV Richard Damon <Richard@Damon-Family.org> - 2015-10-04 21:57 -0400
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:53 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-05 09:37 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 14:10 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-09 14:35 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-10 11:43 +1300
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-12 09:17 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 12:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-12 14:12 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 14:52 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-13 03:00 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-12 23:34 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:00 +0000
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 08:34 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-14 11:34 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-14 11:57 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-15 00:03 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-15 10:57 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-20 16:06 +0000
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-17 07:32 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-17 07:51 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-17 15:51 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:09 +0000
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 08:55 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 08:59 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 17:35 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 10:02 -0700
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:11 -0500
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 17:27 -0400
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-03 16:58 -0500
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 15:16 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:21 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-03 18:23 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-03 18:52 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 16:16 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 19:13 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 23:34 -0700
Re: Unexpected and difficult to understand SIGSEGV glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-04 07:09 +0000
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 14:43 -0700
Re: Unexpected and difficult to understand SIGSEGV Robert Wessel <robertwessel2@yahoo.com> - 2015-10-04 03:19 -0500
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:48 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-04 16:26 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 13:21 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-02 17:05 -0400
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-02 15:11 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 20:55 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-10-03 12:00 -0700
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-03 16:52 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:40 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-10-01 22:02 -0400
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 10:09 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 08:19 -0700
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-02 03:17 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-02 13:02 +0200
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-01 18:33 -0700
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-01 11:17 -0400
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-01 17:06 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 11:45 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-02 10:21 +0000
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 11:36 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 11:44 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 13:24 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 15:31 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 18:04 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 18:21 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-02 21:04 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-03 08:29 +0200
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-03 16:47 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-03 17:37 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-03 17:54 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 18:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 18:13 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 18:22 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 20:17 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-04 21:07 +0100
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:10 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 09:24 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 22:15 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 10:38 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:02 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:10 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:51 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:56 +1300
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 07:38 +1300
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-10-04 23:51 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-04 23:44 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 11:52 +1300
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 00:09 +0100
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-10-05 13:00 +1300
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-10-04 17:14 -0700
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 09:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-10-05 18:32 +0100
Re: Unexpected and difficult to understand SIGSEGV Philip Lantz <prl@canterey.us> - 2015-10-05 21:59 -0700
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:13 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-06 17:14 +0000
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 14:56 +0100
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-10-02 16:31 +0100
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:11 +0100
Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-10-02 09:18 -0700
Re: Unexpected and difficult to understand SIGSEGV Gareth Owen <gwowen@gmail.com> - 2015-10-02 20:14 +0100
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-02 10:20 -0700
Re: Unexpected and difficult to understand SIGSEGV raltbos@xs4all.nl (Richard Bos) - 2015-10-04 14:03 +0000
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-10-01 09:28 -0700
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-01 18:53 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-10-02 06:26 +0200
Generating header files (Was: Unexpected and difficult to understand SIGSEGV) Roberto Waltman <usenet@rwaltman.com> - 2015-10-01 13:40 -0400
Re: Generating header files (Was: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 23:58 +0200
Re: Unexpected and difficult to understand SIGSEGV Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 14:06 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:05 -0400
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:26 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 21:15 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 09:52 -0400
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-28 10:36 -0400
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-28 10:40 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-28 15:55 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-29 01:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 00:26 +0100
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:34 +0200
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 15:50 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 11:16 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 16:22 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 13:15 -0400
Re: Unexpected and difficult to understand SIGSEGV Richard Heathfield <rjh@cpax.org.uk> - 2015-09-29 18:56 +0100
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-29 07:04 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:07 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:13 -0700
Re: Unexpected and difficult to understand SIGSEGV supercat@casperkitty.com - 2015-09-29 21:57 -0700
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 01:57 -0400
Re: Unexpected and difficult to understand SIGSEGV jadill33@gmail.com - 2015-09-30 06:01 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:11 +0200
Re: Unexpected and difficult to understand SIGSEGV Bartc <bc@freeuk.com> - 2015-09-30 14:12 +0100
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:15 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-30 08:40 -0700
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:28 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 22:31 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 16:53 -0400
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:19 +0200
Re: Unexpected and difficult to understand SIGSEGV Rosario19 <Ros@invalid.invalid> - 2015-09-30 23:32 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-30 18:17 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:19 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-30 22:01 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:46 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 17:44 -0700
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 13:51 +1300
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 18:04 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 03:39 +0200
Re: Unexpected and difficult to understand SIGSEGV James Kuyper <jameskuyper@verizon.net> - 2015-09-27 22:03 -0400
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Ian Collins <ian-news@hotmail.com> - 2015-09-28 15:19 +1300
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:23 +0200
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 14:11 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:15 +0200
Re: Unexpected and difficult to understand SIGSEGV Keith Thompson <kst-u@mib.org> - 2015-09-29 18:14 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:41 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-27 19:58 -0700
Re: Unexpected and difficult to understand SIGSEGV David Brown <david.brown@hesbynett.no> - 2015-09-29 10:43 +0200
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 00:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-29 15:51 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-30 16:37 +0200
Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 09:12 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 17:34 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 11:29 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 20:00 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 12:49 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-09-30 22:26 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) supercat@casperkitty.com - 2015-09-30 16:27 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 09:56 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) "Morten W. Petersen" <morphex@gmail.com> - 2015-10-01 03:08 +0200
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 13:10 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 09:23 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:02 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 03:12 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Bartc <bc@freeuk.com> - 2015-10-01 11:15 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Richard Heathfield <rjh@cpax.org.uk> - 2015-10-01 11:36 +0100
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 05:49 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) David Brown <david.brown@hesbynett.no> - 2015-10-01 16:41 +0200
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:16 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-30 19:10 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Ian Collins <ian-news@hotmail.com> - 2015-10-01 15:20 +1300
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Philip Lantz <prl@canterey.us> - 2015-10-01 01:26 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-01 02:16 -0700
Re: Strings (was Re: Unexpected and difficult to understand SIGSEGV) Martin Shobe <martin.shobe@yahoo.com> - 2015-10-01 08:34 -0500
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 19:06 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-28 04:18 +0200
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 21:32 -0700
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 07:54 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-09-27 17:16 +0200
Re: Unexpected and difficult to understand SIGSEGV Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-27 11:21 -0400
Re: Unexpected and difficult to understand SIGSEGV Geoff <geoff@invalid.invalid> - 2015-09-27 08:59 -0700
Re: Unexpected and difficult to understand SIGSEGV "Morten W. Petersen" <morphex@gmail.com> - 2015-10-02 00:16 +0200
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-25 14:08 +0200 |
| Message-ID | <mu3dgc$s5p$1@speranza.aioe.org> |
| In reply to | #71189 |
On 25.09.2015 10:28, jacobnavia wrote: > Le 25/09/2015 04:02, Morten W. Petersen a écrit : >> Hi there. >> >> Once again I'm working on the Smash XML project, and I'm getting a >> SIGSEGV when calling a function. >> >> The line that ends up in a SIGSEGV is >> >> https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/tests.c#L236 >> >> >> >> And gdb says this after "make debug; gdb ./decode_xml": >> >> (gdb) run >> [...] >> test_parse_file >> >> Program received signal SIGSEGV, Segmentation fault. >> __chkstk_ms () at >> /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:172 > > > Excuse me but that is not your program but the source code of gcc itself... > > Unless your software lives in the gcc-4.9.3-1 that code is not you but gdb. I think that code has something to do with the stack. But as suggested elsewhere, that the stack has been mangled earlier is the reason that this error pops up. [...] > Put a breakpoint before the call. The go in machine step by step until > you arrive at the called function: > > command: "stepi" for going instruction by instruction > > command: "x/5i $rip" displays the 5 next instructions beginning with the > current program counter > > command: "display $rcx" will print the contents of rcs at each assembly > step OK. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-25 10:55 +0100 |
| Message-ID | <87eghmg6vo.fsf@bsb.me.uk> |
| In reply to | #71186 |
"Morten W. Petersen" <morphex@gmail.com> writes: > Once again I'm working on the Smash XML project, and I'm getting a > SIGSEGV when calling a function. > > The line that ends up in a SIGSEGV is > > https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/tests.c#L236 > > And gdb says this after "make debug; gdb ./decode_xml": > > (gdb) run > [...] > test_parse_file > > Program received signal SIGSEGV, Segmentation fault. > __chkstk_ms () at /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:172 > 172 orl $0x0, (%ecx) /* probe there */ > (gdb) print $ecx > $1 = 600600 > (gdb) The odds are very high that the error is somewhere else altogether. At a guess, some previous action has messed up the stack. I'd start by turning up warnings and fixing what you see. There seem to be quite a few cases of passing the wrong types for printf formats and one more worrying type error at line 1002. I have no idea if these might be the cause, but I'd always want to remove these things before going any further. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-09-25 14:00 +0200 |
| Message-ID | <mu3d1a$qmv$1@speranza.aioe.org> |
| In reply to | #71190 |
On 25.09.2015 11:55, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> Once again I'm working on the Smash XML project, and I'm getting a >> SIGSEGV when calling a function. >> >> The line that ends up in a SIGSEGV is >> >> https://github.com/morphex/smash_xml/blob/6b558ae0347c04992d0f3c2306373a83d1c2765e/tests.c#L236 >> >> And gdb says this after "make debug; gdb ./decode_xml": >> >> (gdb) run >> [...] >> test_parse_file >> >> Program received signal SIGSEGV, Segmentation fault. >> __chkstk_ms () at /usr/src/debug/gcc-4.9.3-1/libgcc/config/i386/cygwin.S:172 >> 172 orl $0x0, (%ecx) /* probe there */ >> (gdb) print $ecx >> $1 = 600600 >> (gdb) > > The odds are very high that the error is somewhere else altogether. At > a guess, some previous action has messed up the stack. I'd start by > turning up warnings and fixing what you see. There seem to be quite a > few cases of passing the wrong types for printf formats and one more > worrying type error at line 1002. I have no idea if these might be the > cause, but I'd always want to remove these things before going any > further. I googled the error and yes, there was some talk about a messed up stack. I'll try turning up the errors. -Morten
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2015-09-25 09:40 -0700 |
| Message-ID | <744f3f19-7468-4a9b-b9e3-c26f5e99ea4e@googlegroups.com> |
| In reply to | #71192 |
On Friday, September 25, 2015 at 7:01:15 AM UTC-5, Morten W. Petersen wrote: > > I googled the error and yes, there was some talk about a messed up stack. > > I'll try turning up the errors. > An easy way to trash the stack is to write past the end of a buffer allocated on the stack and passed down several levels of function calls. Double-check the termination conditions of all your loops that write into buffers. If that doesn't work, you can change them to malloc'ed buffers and sentinel data (0xDEADBEEF) at the end and check that it's undisturbed before free()ing.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-25 20:25 +0100 |
| Message-ID | <878u7ufgj0.fsf@bsb.me.uk> |
| In reply to | #71198 |
luser droog <luser.droog@gmail.com> writes: > On Friday, September 25, 2015 at 7:01:15 AM UTC-5, Morten W. Petersen wrote: >> >> I googled the error and yes, there was some talk about a messed up stack. >> >> I'll try turning up the errors. >> > > > An easy way to trash the stack is to write past the end of a > buffer allocated on the stack and passed down several levels > of function calls. I don't think there are any (but it was just a quick scan). See below for my best guess at the problem. > Double-check the termination conditions of > all your loops that write into buffers. If that doesn't work, > you can change them to malloc'ed buffers and sentinel data > (0xDEADBEEF) at the end and check that it's undisturbed before > free()ing. That's rather old-fashioned advice. There are ways to check these things automatically now. In fact, the OP is using valgrind if the make file is to be believed. But there are loads of places where a non-void function does not return a value. Sometimes this is a pointer. That can spell trouble for the stack, given what it likely to be taken as the returned value. To the OP: turn up warnings as high as you can and don't try to debug anything more until you have either a clean compile or you are sure that the warnings are just the compiler being fussy (you might want to ask here about specific cases if you are not sure). It's so often a waste of time to rely on dynamic tests (debugging, valgrind etc.) when static analysis is already telling you there are things wrong. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2015-09-25 19:07 -0700 |
| Message-ID | <k7bhdc-9n4.ln1@wilbur.25thandClement.com> |
| In reply to | #71201 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
<snip>
> To the OP: turn up warnings as high as you can and don't try to debug
> anything more until you have either a clean compile or you are sure that
> the warnings are just the compiler being fussy (you might want to ask
> here about specific cases if you are not sure). It's so often a waste
> of time to rely on dynamic tests (debugging, valgrind etc.) when static
> analysis is already telling you there are things wrong.
But that might alter the generated code such that the bug is not manifested
as consistently. Tweaking the build until the symptom disappears is very
poor advice, particularly when faced with a reproducible bug. Fixing a bug
means understanding why the code is broken so that you can reasonably assure
yourself it's been properly addressed. It's almost criminal to suggest
otherwise.
Getting the code to compile cleanly[1] is a good goal, but not as a
substitute for tracking down and fixing a known bug.
[1] Or as clean as reasonable, given that compilers will often complain
about perfectly valid and defensible code. For example, until very recently
both GCC and clang complained about initializing a structure with { 0 } when
the first member was a compound object. { 0 } is the only construct
available when dealing with structures that are supposed to be opaque, and
the only construct for objects with defined members in an undefined order
and where named initializers are not available.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-09-26 10:47 +0100 |
| Message-ID | <8737y1fr6s.fsf@bsb.me.uk> |
| In reply to | #71209 |
<william@wilbur.25thandClement.com> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > <snip> >> To the OP: turn up warnings as high as you can and don't try to debug >> anything more until you have either a clean compile or you are sure that >> the warnings are just the compiler being fussy (you might want to ask >> here about specific cases if you are not sure). It's so often a waste >> of time to rely on dynamic tests (debugging, valgrind etc.) when static >> analysis is already telling you there are things wrong. > > But that might alter the generated code such that the bug is not manifested > as consistently. Tweaking the build until the symptom disappears is very > poor advice, particularly when faced with a reproducible bug. Fixing a bug > means understanding why the code is broken so that you can reasonably assure > yourself it's been properly addressed. It's almost criminal to suggest > otherwise. Strong words. But I can't agree in this case. You are perfectly correct when the code is more advanced, but this is a first pass by a beginner. Trying to find and understand *this* particular bug is pointless when the code still as dozens of errors. In fact it won't compile with one compiler I tried because it treated some of the issues as errors rather than warnings. I spotted a dozen serious problems on inspection, any of which might cause unpredictable behaviour, on a relatively casual inspection. This is not production code with a tricky bug that needs to be understood. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-09-26 10:34 -0400 |
| Message-ID | <5606ACFC.9000704@verizon.net> |
| In reply to | #71209 |
On 09/25/2015 10:07 PM, william@wilbur.25thandClement.com wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > <snip> >> To the OP: turn up warnings as high as you can and don't try to debug >> anything more until you have either a clean compile or you are sure that >> the warnings are just the compiler being fussy (you might want to ask >> here about specific cases if you are not sure). It's so often a waste >> of time to rely on dynamic tests (debugging, valgrind etc.) when static >> analysis is already telling you there are things wrong. > > But that might alter the generated code such that the bug is not manifested > as consistently. Tweaking the build until the symptom disappears is very > poor advice, particularly when faced with a reproducible bug. Fixing a bug > means understanding why the code is broken so that you can reasonably assure > yourself it's been properly addressed. It's almost criminal to suggest > otherwise. > > Getting the code to compile cleanly[1] is a good goal, but not as a > substitute for tracking down and fixing a known bug. True - but sometimes getting the code to compile cleanly IS tracking down and fixing a known bug. In my experience, particularly when dealing with newbie code (and Morten definitely seems to be a newbie), the actual code defect is often directly related to one of those warning messages. Even if getting the code to compile cleanly makes the bug less easily repeatable, without actually removing the bug, doing so can still make debugging easier. If the warning is about a construct that can have undefined behavior, as is often the case, then it's much easier to figure out what's going wrong if you first change the code so that the behavior is always defined. Otherwise, the consequences of any changes you make to investigate the problem are unpredictable. Once the behavior is well-defined, then you can find out why the defined behavior of that code isn't achieving the desired results.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-26 15:28 +0000 |
| Message-ID | <slrnn0dedl.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71209 |
On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote:
...
> Getting the code to compile cleanly[1] is a good goal [...]
> [1] Or as clean as reasonable, given that compilers will often complain
> about perfectly valid and defensible code.
Even with gcc -Wall -Wextra -pedantic, I don't find that extremely
common. Most of my code compiles without warnings, and that's not
because I've warped it to please the compiler.
(Not counting unused function/parameter/variable warnings, where
fixing them can actually decrease your code quality.)
But you're right: crank up the warning level, and don't panic if you
see a warning. Treat it seriously: /understand/ why you're seeing it,
and consider doing something about it.
> For example, until very recently both GCC and clang complained
> about initializing a structure with { 0 } when the first member
> was a compound object. [...]
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-26 17:32 -0700 |
| Message-ID | <kfn37y0em7i.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71220 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: > ... >> Getting the code to compile cleanly[1] is a good goal [...] >> >> [1] Or as clean as reasonable, given that compilers will often complain >> about perfectly valid and defensible code. > > Even with gcc -Wall -Wextra -pedantic, I don't find that extremely > common. Most of my code compiles without warnings, and that's not > because I've warped it to please the compiler. This doesn't match my experience. Last time I looked about half of the conditions covered by -Wall and -Wextra are ones that should be enabled at all times. The other half are a mixed bag, ranging from an occasional false positive to pointless or worse. But then my view of how seriously warnings should be treated may be more severe than yours; I advocate -Werror in all production compiles. I completely agree on -pedantic (except perhaps to strengthen it to -pedantic-errors). > But you're right: crank up the warning level, and don't panic if > you see a warning. Treat it seriously: /understand/ why you're > seeing it, and consider doing something about it. I agree here as a step to help track down a bug. My point earlier was about which conditions to flag in all cases, which is different from what to do for spot checks.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2015-09-27 09:59 +0200 |
| Message-ID | <mu87gn$o8s$1@dont-email.me> |
| In reply to | #71248 |
On 27/09/2015 02:32, Tim Rentsch wrote:
> This doesn't match my experience. Last time I looked about half
> of the conditions covered by -Wall and -Wextra are ones that
> should be enabled at all times. The other half are a mixed bag,
> ranging from an occasional false positive to pointless or worse.
I wouldn't group -Wall and -Wextra, as -Wall is intended to be
"generally" accepted warnings, while -Wextra may have more
"debatable" warnings.
<quote>
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/Warning-Options.html
-Wall enables all the warnings about constructions that some users
consider questionable, and that are easy to avoid (or modify to
prevent the warning), even in conjunction with macros.
-Wextra enables some extra warning flags that are not enabled by -Wall.
Note that some warning flags are not implied by -Wall. Some of them
warn about constructions that users generally do not consider
questionable, but which occasionally you might wish to check for;
others warn about constructions that are necessary or hard to avoid
in some cases, and there is no simple way to modify the code to
suppress the warning. Some of them are enabled by -Wextra but many of
them must be enabled individually.
-Wall turns on the following warning flags:
-Waddress
-Warray-bounds (only with -O2)
-Wc++11-compat
-Wchar-subscripts
-Wenum-compare (in C/ObjC; this is on by default in C++)
-Wimplicit-int (C and Objective-C only)
-Wimplicit-function-declaration (C and Objective-C only)
-Wcomment
-Wformat
-Wmain (only for C/ObjC and unless -ffreestanding)
-Wmaybe-uninitialized
-Wmissing-braces (only for C/ObjC)
-Wnonnull
-Wopenmp-simd
-Wparentheses
-Wpointer-sign
-Wreorder
-Wreturn-type
-Wsequence-point
-Wsign-compare (only in C++)
-Wstrict-aliasing
-Wstrict-overflow=1
-Wswitch
-Wtrigraphs
-Wuninitialized
-Wunknown-pragmas
-Wunused-function
-Wunused-label
-Wunused-value
-Wunused-variable
-Wvolatile-register-var
-Wextra turns on the following warning flags:
-Wclobbered
-Wempty-body
-Wignored-qualifiers
-Wmissing-field-initializers
-Wmissing-parameter-type (C only)
-Wold-style-declaration (C only)
-Woverride-init
-Wsign-compare
-Wtype-limits
-Wuninitialized
-Wunused-parameter (only with -Wunused or -Wall)
-Wunused-but-set-parameter (only with -Wunused or -Wall)
Regards.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-30 02:52 -0700 |
| Message-ID | <kfneghgb5f7.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71259 |
Noob <root@127.0.0.1> writes: > On 27/09/2015 02:32, Tim Rentsch wrote: > >> This doesn't match my experience. Last time I looked about half >> of the conditions covered by -Wall and -Wextra are ones that >> should be enabled at all times. The other half are a mixed bag, >> ranging from an occasional false positive to pointless or worse. > > I wouldn't group -Wall and -Wextra, [snip elaboration] I did because the posting I was responding to did. Having said that, my recollection is that the "about half" measure held independently for -Wall as well as -Wextra.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2015-09-30 20:13 +0200 |
| Message-ID | <muh8k0$ubu$1@dont-email.me> |
| In reply to | #71471 |
On 30/09/2015 11:52, Tim Rentsch wrote: > Noob <root@127.0.0.1> writes: > >> On 27/09/2015 02:32, Tim Rentsch wrote: >> >>> This doesn't match my experience. Last time I looked about half >>> of the conditions covered by -Wall and -Wextra are ones that >>> should be enabled at all times. The other half are a mixed bag, >>> ranging from an occasional false positive to pointless or worse. >> >> I wouldn't group -Wall and -Wextra, [snip elaboration] > > I did because the posting I was responding to did. Having > said that, my recollection is that the "about half" measure > held independently for -Wall as well as -Wextra. Y'know, gcc is an open source work-in-progress. If some warnings enabled by -Wall are, as you claim, "pointless or worse" then that should be considered a bug, which should be pointed out either on the mailing list or on Bugzilla. If you give me example code that triggers bad warnings, I'll send it to the appropriate channels. Regards.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 16:00 -0700 |
| Message-ID | <kfnmvvy6xzd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71491 |
Noob <root@127.0.0.1> writes: > On 30/09/2015 11:52, Tim Rentsch wrote: >> Noob <root@127.0.0.1> writes: >> >>> On 27/09/2015 02:32, Tim Rentsch wrote: >>> >>>> This doesn't match my experience. Last time I looked about half >>>> of the conditions covered by -Wall and -Wextra are ones that >>>> should be enabled at all times. The other half are a mixed bag, >>>> ranging from an occasional false positive to pointless or worse. >>> >>> I wouldn't group -Wall and -Wextra, [snip elaboration] >> >> I did because the posting I was responding to did. Having >> said that, my recollection is that the "about half" measure >> held independently for -Wall as well as -Wextra. > > Y'know, gcc is an open source work-in-progress. > > If some warnings enabled by -Wall are, as you claim, "pointless > or worse" then that should be considered a bug, which should be > pointed out either on the mailing list or on Bugzilla. I didn't mean to say that exactly - the "bad" -Wall conditions may be more at the "false positive" end of the spectrum rather than the "pointless or worse" end. Also some of these are purely about style choices - I don't want to get into a style argument. > If you give me example code that triggers bad warnings, I'll > send it to the appropriate channels. I appreciate the offer. I think there is a key difference in how different people see "warnings", namely whether the flagged code is "probably wrong" or "deserves review". Usually I take the first perspective, whereas I expect the gcc community is more in line with the second perspective. It would be good to have a more extensive discussion about that, but I don't think a bug report is a good place to start that discussion. I think the issue is important but it's hard to do something about it without a comparatively large change in gcc group mindset. Or if not large then at least one I don't know how to initiate.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-09-28 08:17 +0000 |
| Message-ID | <slrnn0httc.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71248 |
On Sun, 2015-09-27, Tim Rentsch wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > >> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >> ... >>> Getting the code to compile cleanly[1] is a good goal [...] >>> >>> [1] Or as clean as reasonable, given that compilers will often complain >>> about perfectly valid and defensible code. >> >> Even with gcc -Wall -Wextra -pedantic, (There should have been a -std=c99 in that list by the way.) >> I don't find that extremely >> common. Most of my code compiles without warnings, and that's not >> because I've warped it to please the compiler. > > This doesn't match my experience. Last time I looked about half > of the conditions covered by -Wall and -Wextra are ones that > should be enabled at all times. The other half are a mixed bag, > ranging from an occasional false positive to pointless or worse. > But then my view of how seriously warnings should be treated may > be more severe than yours; I advocate -Werror in all production > compiles. And I'm rather firmly against -Werror ... although I'm also against the idea of tolerating that a build generates a lot of warnings which everyone ignores ... So I'm not against -Werror because my code compiles with a lot of warnings. I rarely let a single warning slip into a commit. I cannot explain our different experiences. I don't think it's because your code is sloppy or unsafe. It's possible that without thinking about it, I've adjusted my style to gcc -Wall -Wextra ... Or perhaps we write code for different problem domains. > I completely agree on -pedantic (except perhaps to strengthen it > to -pedantic-errors). > >> But you're right: crank up the warning level, and don't panic if >> you see a warning. Treat it seriously: /understand/ why you're >> seeing it, and consider doing something about it. > > I agree here as a step to help track down a bug. My point > earlier was about which conditions to flag in all cases, > which is different from what to do for spot checks. Ok. And I recommend it all the time, so we disagree here. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-30 04:00 -0700 |
| Message-ID | <kfna8s4b28m.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71359 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Sun, 2015-09-27, Tim Rentsch wrote: >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> >>> On Sat, 2015-09-26, <william@wilbur.25thandClement.com> wrote: >>> ... >>>> Getting the code to compile cleanly[1] is a good goal [...] >>>> >>>> [1] Or as clean as reasonable, given that compilers will often complain >>>> about perfectly valid and defensible code. >>> >>> Even with gcc -Wall -Wextra -pedantic, > > (There should have been a -std=c99 in that list by the way.) Okay, good to hear. :) >>> I don't find that extremely >>> common. Most of my code compiles without warnings, and that's not >>> because I've warped it to please the compiler. >> >> This doesn't match my experience. Last time I looked about half >> of the conditions covered by -Wall and -Wextra are ones that >> should be enabled at all times. The other half are a mixed bag, >> ranging from an occasional false positive to pointless or worse. >> But then my view of how seriously warnings should be treated may >> be more severe than yours; I advocate -Werror in all production >> compiles. > > And I'm rather firmly against -Werror ... although I'm also against > the idea of tolerating that a build generates a lot of warnings which > everyone ignores ... > > So I'm not against -Werror because my code compiles with a lot of > warnings. I rarely let a single warning slip into a commit. I cannot > explain our different experiences. I don't think it's because your > code is sloppy or unsafe. It sounds like your attitude toward clean compiles is pretty similar to mine. (There is more to say on that which I get to below.) > It's possible that without thinking about > it, I've adjusted my style to gcc -Wall -Wextra ... Probably so, at least to some extent. > Or perhaps we write code for different problem domains. Maybe. I'd be surprised if that is a factor here. >> I completely agree on -pedantic (except perhaps to strengthen it >> to -pedantic-errors). >> >>> But you're right: crank up the warning level, and don't panic if >>> you see a warning. Treat it seriously: /understand/ why you're >>> seeing it, and consider doing something about it. >> >> I agree here as a step to help track down a bug. My point >> earlier was about which conditions to flag in all cases, >> which is different from what to do for spot checks. > > Ok. And I recommend it all the time, so we disagree here. I think our views are closer than it might seem. I glossed over a point about workflow, which may explain the apparent differences. Let me elaborate on that. I distinguish (at least) three different kinds of compilations: development, code review, and production. The development kind is what an individual developer does during his/her regular daily work. The code review kind is what is done just before (and in anticipation of) doing a code review. The production kind is what is done as part of the check-in/commit process, for any group-available complete build. For development compilations, I think the choice of which options to use may be left up to individual developers as they see fit. I may recommend using at least a minimal set of diagnostics, but what they use is up to them; that may be a less restrictive set, or a more restrictive set, or it may change as a function of how far along the development is. I think it's counterproductive to micro-manage that choice. For code review compilations the bar is higher. Here there is a specified set of diagnostic conditions, with -Werror, and also an additional compilation with a larger set of condtions (and not requiring -Werror). The first set of conditions must pass as a pre-requisite to code review. The second set of conditions may generate additional diagnostics, which are part of the input to doing the code review. The developer(s) whose code is being reviewed may be asked to defend any code that causes a warning. For production compilations, there is a specified set of diagnostic conditions (probably the same as the first code review set, but that doesn't have to be true), including using a -Werror option. Any submission that fails to compile is not accepted for that build, with no exceptions. My guess is most of the compiles you do are done in a mindset roughly akin to the "code review" step in the model above (even when you don't anticipate any actual review being done). If that is so then it looks like our views are pretty close together. One additional comment about -Wall/-Wextra. I advocate not using these option flags directly, but explicitly using the set of options they expand into (or perhaps subset, if there are particular ones thought better left out). The reason for this is that the set of conditions tested by -Wall/-Wextra changes over time, so previously clean compiles may suddenly acquire warnings they didn't have before (and there is more to say about that, which I won't get into right now). But this is a minor detail that doesn't really affect the comments above.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-01 09:34 +1300 |
| Message-ID | <d72vauFqr3pU30@mid.individual.net> |
| In reply to | #71475 |
Tim Rentsch wrote: > > I think our views are closer than it might seem. I glossed > over a point about workflow, which may explain the apparent > differences. Let me elaborate on that. > > I distinguish (at least) three different kinds of compilations: > development, code review, and production. The development kind > is what an individual developer does during his/her regular > daily work. The code review kind is what is done just before > (and in anticipation of) doing a code review. The production > kind is what is done as part of the check-in/commit process, > for any group-available complete build. It's interesting how different people's view of normal is. I would always use the same diagnostics for all compiles. Mistakes should be spotted and corrected as early as possible in the development process, so if anything the development compiles should be the ones with the most robust checking. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-01 19:05 +0000 |
| Message-ID | <slrnn0r0vb.eij.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71503 |
On Wed, 2015-09-30, Ian Collins wrote: > Tim Rentsch wrote: >> >> I think our views are closer than it might seem. I glossed >> over a point about workflow, which may explain the apparent >> differences. Let me elaborate on that. >> >> I distinguish (at least) three different kinds of compilations: >> development, code review, and production. The development kind >> is what an individual developer does during his/her regular >> daily work. The code review kind is what is done just before >> (and in anticipation of) doing a code review. The production >> kind is what is done as part of the check-in/commit process, >> for any group-available complete build. > > It's interesting how different people's view of normal is. I would > always use the same diagnostics for all compiles. Mistakes should be > spotted and corrected as early as possible in the development process, > so if anything the development compiles should be the ones with the most > robust checking. Don't you see certain warning options as giving mostly false positives, which are also hard to silence without making the code worse? I have a few of those on my list, e.g. the one about unused functions. I want to see some of them while my work is still not published, but I don't want them to prevent publishing. At least one "linter" tool I've seen (Coverity Prevent) solved that for its own linter warnings, by keeping a project-wide database of warnings, and letting you input "don't mind this warning on this line; I've checked it and it's a false positive". But that raises other issues: you now have in effect one aspect of the code hidden away in yet another separate system. I'm undecided ... I think seeing the different kinds of compilations like TR does is a good insight. And the combination of -Werror and errors for unused functions/ parameters/variables really slowed down my work in a past project -- made me produce worse code, more slowly. Although you could argue that was a build system problem ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-02 08:25 +1300 |
| Message-ID | <d75fkfF7jicU3@mid.individual.net> |
| In reply to | #71556 |
Jorgen Grahn wrote: > On Wed, 2015-09-30, Ian Collins wrote: >> Tim Rentsch wrote: >>> >>> I think our views are closer than it might seem. I glossed >>> over a point about workflow, which may explain the apparent >>> differences. Let me elaborate on that. >>> >>> I distinguish (at least) three different kinds of compilations: >>> development, code review, and production. The development kind >>> is what an individual developer does during his/her regular >>> daily work. The code review kind is what is done just before >>> (and in anticipation of) doing a code review. The production >>> kind is what is done as part of the check-in/commit process, >>> for any group-available complete build. >> >> It's interesting how different people's view of normal is. I would >> always use the same diagnostics for all compiles. Mistakes should be >> spotted and corrected as early as possible in the development process, >> so if anything the development compiles should be the ones with the most >> robust checking. > > Don't you see certain warning options as giving mostly false > positives, which are also hard to silence without making the code > worse? I have a few of those on my list, e.g. the one about unused > functions. I want to see some of them while my work is still not > published, but I don't want them to prevent publishing. No because with TDD there won't be any unused functions or variables. Everything is written to pass a test and the aim is to have tested code ready to ship ant any time. So in effect, all builds are release builds :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 16:02 -0700 |
| Message-ID | <kfnio6m6xv6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71503 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: > >> I think our views are closer than it might seem. I glossed >> over a point about workflow, which may explain the apparent >> differences. Let me elaborate on that. >> >> I distinguish (at least) three different kinds of compilations: >> development, code review, and production. The development kind >> is what an individual developer does during his/her regular >> daily work. The code review kind is what is done just before >> (and in anticipation of) doing a code review. The production >> kind is what is done as part of the check-in/commit process, >> for any group-available complete build. > > It's interesting how different people's view of normal is. I > would always use the same diagnostics for all compiles. Mistakes > should be spotted and corrected as early as possible in the > development process, so if anything the development compiles > should be the ones with the most robust checking. That depends on whether you think all circumstances reported by gcc's warning sets represent mistakes. I don't. Some of those circumstances represent mistakes, but not all of them.
[toc] | [prev] | [next] | [standalone]
Page 2 of 17 — ← Prev page 1 [2] 3 4 … 17 Next page →
Back to top | Article view | comp.lang.c
csiph-web