Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.

On 06/08/2012 11:30 AM, "Jarl André" <jarl.andre@gmail.com>" wrote:
> Evry single time I encounter them I yawn. It means using the next
> frickin hour to comment away code, add more log statements and try to
> eleminate whats creating the hell of bugz, segmantation fault. Why can't
> the compiler tell me anything else than the fact that i have referenced
> data that does not exist? Thanks I knew that. Now, please tell me where
> the error occured.... Jeezes.

If you build with -debug, it should enable code that will do those checks for you in things like arrays and associative arrays (where I find I have the most problems). It'll throw an exception rather than segfault. Very handy.

On Fri, 08 Jun 2012 19:30:57 +0200, Jarl André wrote:

> Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.

The compiler can't really help you (aside from maybe adding dereference checks everywhere) because you have a logic error, not something that can be statically determined. This is why debuggers exist. Whenever I get a segfault, I fire up GDB and recreate it. If you've compiled with -g, GDB can usually tell you the exact line the problem occurred on and a full backtrace to help you figure out how you got there.

On 08.06.2012 21:30, "Jarl André" <jarl.andre@gmail.com>" wrote:
> Evry single time I encounter them I yawn. It means using the next
> frickin hour to comment away code, add more log statements and try to
> eleminate whats creating the hell of bugz, segmantation fault. Why can't
> the compiler tell me anything else than the fact that i have referenced
> data that does not exist? Thanks I knew that. Now, please tell me where
> the error occured.... Jeezes.

Well there should be a stack trace. I even see it on win32 these days.

try compiling with -g flag.

-- 
Dmitry Olshansky

On Friday, June 08, 2012 19:30:57 Jarl André" <jarl.andre@gmail.com>@puremagic.com wrote:
> Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.

Turn on core dumps and use gdb. It'll give a backtrace and allow you to look at the state of the program when the segfault occured. That's pretty much the standard way to figure out what happened when a segfault occurs.

- Jonathan M Davis

On Fri, Jun 8, 2012 at 11:29 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> On Friday, June 08, 2012 19:30:57 Jarl André" <jarl.andre@gmail.com>@puremagic.com wrote:
> > Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.
>
> Turn on core dumps and use gdb. It'll give a backtrace and allow you to
> look
> at the state of the program when the segfault occured. That's pretty much
> the
> standard way to figure out what happened when a segfault occurs.
>

And use GDC because DMD's debug symbols on Linux are broken enough to crash GDB at times. GDC is generally flawless.

On Fri, 08 Jun 2012 19:57:47 -0700, Andrew Wiley wrote:

> On Fri, Jun 8, 2012 at 11:29 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> 
>> On Friday, June 08, 2012 19:30:57 Jarl André" <jarl.andre@gmail.com>@puremagic.com wrote:
>> > Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.
>>
>> Turn on core dumps and use gdb. It'll give a backtrace and allow you to
>> look
>> at the state of the program when the segfault occured. That's pretty
>> much the
>> standard way to figure out what happened when a segfault occurs.
>>
>>
> And use GDC because DMD's debug symbols on Linux are broken enough to crash GDB at times. GDC is generally flawless. <div class="gmail_quote">On Fri, Jun 8, 2012 at 11:29 AM, Jonathan M Davis <span dir="ltr">&lt;<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-
width:1px;border-left-style:solid">
> 
> 
> On Friday, June 08, 2012 19:30:57 Jarl André&quot;<br> <div><div>&lt;<a
> href="mailto:jarl.andre@gmail.com"
> target="_blank">jarl.andre@gmail.com</a>&gt;@<a
> href="http://puremagic.com" target="_blank">puremagic.com</a> wrote:<br>
> &gt; Evry single time I encounter them I yawn. It means using the
> next<br> &gt; frickin hour to comment away code, add more log statements
> and<br> &gt; try to eleminate whats creating the hell of bugz,
> segmantation<br> &gt; fault. Why can&#39;t the compiler tell me anything
> else than the fact<br> &gt; that i have referenced data that does not
> exist? Thanks I knew<br> &gt; that. Now, please tell me where the error
> occured.... Jeezes.<br> <br>
> </div></div>Turn on core dumps and use gdb. It&#39;ll give a backtrace
> and allow you to look<br> at the state of the program when the segfault
> occured. That&#39;s pretty much the<br> standard way to figure out what
> happened when a segfault occurs.<br> </blockquote><div> </div><div>And
> use GDC because DMD&#39;s debug symbols on Linux are broken enough to
> crash GDB at times. GDC is generally flawless. </div></div>

Ah noes, HTML code again...



-- 
Dejan Lekic
  mailto:dejan.lekic(a)gmail.com
  http://dejan.lekic.org

On Sat, Jun 9, 2012 at 6:09 AM, Dejan Lekic <dejan.lekic@gmail.com> wrote:
> On Fri, 08 Jun 2012 19:57:47 -0700, Andrew Wiley wrote:
>
>> On Fri, Jun 8, 2012 at 11:29 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
>>
>>> On Friday, June 08, 2012 19:30:57 Jarl André" <jarl.andre@gmail.com>@puremagic.com wrote:
>>> > Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.
>>>
>>> Turn on core dumps and use gdb. It'll give a backtrace and allow you to
>>> look
>>> at the state of the program when the segfault occured. That's pretty
>>> much the
>>> standard way to figure out what happened when a segfault occurs.
>>>
>>>
>> And use GDC because DMD's debug symbols on Linux are broken enough to crash GDB at times. GDC is generally flawless.
> Ah noes, HTML code again...


Sorry, my bad. Better?

On 06/08/2012 02:00 PM, Justin Whear wrote:
> On Fri, 08 Jun 2012 19:30:57 +0200, Jarl André wrote:
>
>> Evry single time I encounter them I yawn. It means using the next
>> frickin hour to comment away code, add more log statements and try to
>> eleminate whats creating the hell of bugz, segmantation fault. Why can't
>> the compiler tell me anything else than the fact that i have referenced
>> data that does not exist? Thanks I knew that. Now, please tell me where
>> the error occured.... Jeezes.
>
> The compiler can't really help you (aside from maybe adding dereference
> checks everywhere) because you have a logic error, not something that can
> be statically determined. This is why debuggers exist. Whenever I get a
> segfault, I fire up GDB and recreate it. If you've compiled with -g, GDB
> can usually tell you the exact line the problem occurred on and a full
> backtrace to help you figure out how you got there.

I think what everyone who didn't come from a C/C++ background wants is backtraces without having to drop into a debugger.

I just don't think the folks that haven't used modern JITed/interpreted languages for a long period of time understand how inconvenient (and sometimes completely impractical) it is to drop into a debugger every time there is a segfault.

Le vendredi 08 juin 2012 à 19:30 +0200, Jarl =?UTF-8?B?QW5kcsOpIg==?= a écrit :
> Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured.... Jeezes.

Hi, te best way that is to use ldc or gdc with -g flag
i use ldc2 me from fedora repo
$ sudo yum install ldc2* // install D compiler, D standard library,
headers ...
$ sudo yum install dustmite // this tool are really help full to get a
minimall test cease
$ ulimit -c unlimited // able to generate core dump
$ ldc2 myProgram.d
$ ./dustmite_snippet.sh myProgram
---------------------
$ cat ./dustmite_snippet.sh
#!/bin/sh
BINARY=$1 #the binary to test
SEGFUNC="_aaDelX" #the function where the segfault occurs (as in the gdb
backtrace!)
ldc2 $1.d -of$BINARY 2>/dev/null #Your compile command

echo $(sh -c "./$BINARY" 2>&1) | grep -q "Erreur de segmentation" #Make
sure there was a segfault
if [ $? -eq 0 ]
then
    gdb --batch -ex 'backtrace' $BINARY core 2>&1 | grep -q "#0 .* in
$SEGFUNC"
    if [ $? -eq 0 ]
    then
        return 0
    else
        return 1
    fi
else
    return 1
fi