On Tue, 13 Jul 2010 08:48:50 -0400, Steven Schveighoffer wrote:

> On Tue, 13 Jul 2010 02:26:22 -0400, Graham St Jack <Graham.StJack@internode.on.net> wrote:
> 
>> I have jumped back onto the D2 band-wagon after a long absence, read Andrei's book, and am having a great time cutting heaps of D code. My increase in productivity and happiness when compared to working in C++ is enormous.
>>
>> Bug thumbs up to everyone involved with D2, Phobos and the book.
>>
>> One area I am having a bit of trouble with is debugging. Can anyone help me out with how to debug a D2 program in Linux? Currently I am reduced to printing out heaps of debug text.
>>
>> Specifically:
>>
>> Stack Trace:
>> ------------
>>
>> I can't get the D2 stack-trace to work properly. All I get is something like this, which isn't helpful:
>>
>> Segmentation fault
>>
>> The code I used to generate this was: import std.stdio;
>> import std.file;
>> void foo(File file) {
>>     file.flush;
>> }
>> void main(string[] args) {
>>     File file;
>>     foo(file);
>> }
>> Is stack-trace support broken, or do I have to do something to enable
>> it?
> 
> Seg faults do not generate stack traces in Linux/MacOS.  This is because a segmentation fault is generated by a signal, and it's unsafe to throw exceptions from signals.
> 
> I believe seg faults can generate exceptions in Windows, but I'm not sure.
> 
> Your best bet is to get a debugger working, and it will halt on the signal.  As I understand it, a lot of good work was done recently on dmd (can't remember who did it) to get it working better with gdb.
> 
> -Steve

Thanks. I will persist with gdb and look forward to the D support coming through.

On 07/13/2010 04:41 PM, Graham St Jack wrote:
> On Tue, 13 Jul 2010 10:34:41 -0500, Andrei Alexandrescu wrote:
>
>> On 07/13/2010 01:26 AM, Graham St Jack wrote:
>>> I have jumped back onto the D2 band-wagon after a long absence, read
>>> Andrei's book, and am having a great time cutting heaps of D code. My
>>> increase in productivity and happiness when compared to working in C++
>>> is enormous.
>>>
>>> Bug thumbs up to everyone involved with D2, Phobos and the book.
>> [snip]
>>
>> Thanks. Bug thumbs up? Clearly you had debugging on your mind :o).
>>
>> Check http://www.zerobugs.org/.
>>
>>
>> Andrei
>
> Freudian slip...
>
> I love the book by the way - I couldn't put it down. D is totally awesome
> now, and there were heaps of cool new features that I didn't know about.
>
> Thanks again.

*cough* amazon *cough* review *cough*

Andrei

On Tue, 13 Jul 2010 21:38:09 +0000, Graham St Jack wrote:

> On Tue, 13 Jul 2010 03:55:08 -0400, bearophile wrote:
> 
>> Graham St Jack:
>>> How do I profile a D2 program? When I try -profile in dmd, the resultant executable crashes with a segfault when I try to run it.
>> 
>> Are you able to produce a small test case of this bug?
>> 
>> Bye,
>> bearophile
> 
> Small test cases don't crash. I will spend a bit of time experimenting with my way-too-big test case to find out why it crashes when run after being compiled with -profile, and post my results here.
> 
> One thing I noticed was that the trace.log file doesn't demangle the names properly either.

Here is a gdb stacktrace from a program that was compiled with -profile and -gc. The program is too big to post here, but it works just fine without the -profile. Note that the problem seems to be something to do with variant and/or concurrency. I don't like my chances, but I will dig deeper.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf7521b70 (LWP 32218)]
0x080834cc in trace_epi ()
(gdb) bt
#0  0x080834cc in trace_epi ()
#1  0x0806ee56 in _trace_epi_n ()
#2  0xf7520ee4 in ?? ()
#3  0x08057b4d in
_D3std7variant17__T8VariantNVk24Z8VariantN59__T7handlerTS3std8typecons24__T5TupleTC3bob7NewFileZ5TupleZ7handlerFE3std7variant17__T8VariantNVk24Z8VariantN4OpIDPG24hPvZi
(parm=0xf7520eac, pStore=0x0,
    selector=3) at /home/grahams/local/dmd2/linux/bin/../../src/phobos/
std/variant.d:248
#4  0x08061310 in
_D3std7variant17__T8VariantNVk24Z8VariantN62__T10convertsToTS3std8typecons23__T5TupleTC3bob6ActionZ5TupleZ10convertsToMFZb
(this=0xf7520ec8)
    at /home/grahams/local/dmd2/linux/bin/../../src/phobos/std/
variant.d:584
#5  0x080607ec in
_D3std11concurrency10MessageBox130__T3getTDFS3std11concurrency3TidZvTDFC3bob6ActionZvTDFC3bob7NewFileZvTDFAyaZvTDFC3bob11UpdatedFileZvTDFC3bob11ScannedFileZvTDFbZvZ3getMFDFS3std11concurrency3TidZvDFC3bob6ActionZvDFC3bob7NewFileZvDFAyaZvDFC3bob11UpdatedFileZvDFC3bob11ScannedFileZvDFbZvZv9onUserMsgMFS3std11concurrency7MessageZb
(this=0xf7521038, msg=...)
    at /home/grahams/local/dmd2/linux/bin/../../src/phobos/std/
concurrency.d:360
#6  0x08061213 in
_D3std11concurrency10MessageBox130__T3getTDFS3std11concurrency3TidZvTDFC3bob6ActionZvTDFC3bob7NewFileZvTDFAyaZvTDFC3bob11UpdatedFileZvTDFC3bob11ScannedFileZvTDFbZvZ3getMFDFS3std11concurrency3TidZvDFC3bob6ActionZvDFC3bob7NewFileZvDFAyaZvDFC3bob11UpdatedFileZvDFC3bob11ScannedFileZvDFbZvZv4scanMFKS3std11concurrency36__T4ListTS3std11concurrency7MessageZ4ListZb
(this=0xf7521038, list=0xf7d26dc8)
    at /home/grahams/local/dmd2/linux/bin/../../src/phobos/std/
concurrency.d:449
#7  0x08060555 in
_D3std11concurrency10MessageBox130__T3getTDFS3std11concurrency3TidZvTDFC3bob6ActionZvTDFC3bob7NewFileZvTDFAyaZvTDFC3bob11UpdatedFileZvTDFC3bob11ScannedFileZvTDFbZvZ3getMFDFS3std11concurrency3TidZvDFC3bob6ActionZvDFC3bob7NewFileZvDFAyaZvDFC3bob11UpdatedFileZvDFC3bob11ScannedFileZvDFbZvZv
(this=0xf7d26dc0, _param_6=577956023555583664,
_param_5=577955439440031408, _param_4=577954855324479152,
    _param_3=577954408647880368, _param_2=577953807352458928,
_param_1=577952742200569520, _param_0=577952226804494000) at /home/
grahams/local/dmd2/linux/bin/../../src/phobos/std/concurrency.d:463
#8  0x080603f0 in
_D3std11concurrency134__T7receiveTDFS3std11concurrency3TidZvTDFC3bob6ActionZvTDFC3bob7NewFileZvTDFAyaZvTDFC3bob11UpdatedFileZvTDFC3bob11ScannedFileZvTDFbZvZ7receiveFDFS3std11concurrency3TidZvDFC3bob6ActionZvDFC3bob7NewFileZvDFAyaZvDFC3bob11UpdatedFileZvDFC3bob11ScannedFileZvDFbZvZv
(_param_6=577956023555583664, _param_5=577955439440031408,
_param_4=577954855324479152, _param_3=577954408647880368,
    _param_2=577953807352458928, _param_1=577952742200569520,
_param_0=577952226804494000) at /home/grahams/local/dmd2/linux/bin/../../
src/phobos/std/concurrency.d:228
#9  0x08054c18 in _D3bob13do_schedulingFbS3std11concurrency3TidZv
(done_tid=..., print_deps=false) at /home/grahams/source/squid/open/
bedrock/build-tool/util/bob.d:2127
#10 0x08067bfc in
_D3std11concurrency35__T5spawnTbTS3std11concurrency3TidZ5spawnFPFbS3std11concurrency3TidZvbS3std11concurrency3TidZS3std11concurrency3Tid4execMFZv
(this=0xf7d27b80)
    at /home/grahams/local/dmd2/linux/bin/../../src/phobos/std/
concurrency.d:154
#11 0x0806c00e in _D4core6thread6Thread3runMFZv ()
#12 0x0807df2a in thread_entryPoint ()
#13 0xf7faa96e in start_thread (arg=0xf7521b70) at pthread_create.c:300
#14 0xf7ef3b5e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

-profile currently doesn't work with multithreaded apps.

On Fri, 16 Jul 2010 21:47:50 +0000, Sean Kelly wrote:

> -profile currently doesn't work with multithreaded apps.

Darn. Are there plans to sort that out?

Graham St Jack Wrote:

> On Fri, 16 Jul 2010 21:47:50 +0000, Sean Kelly wrote:
> 
> > -profile currently doesn't work with multithreaded apps.
> 
> Darn. Are there plans to sort that out?

It's been on my "to do" list for ages.  Timing data is less/differently useful for multithreaded code, but it should at least not crash, unlike now.

On Sat, 17 Jul 2010 14:43:38 -0400, Sean Kelly wrote:

> Graham St Jack Wrote:
> 
>> On Fri, 16 Jul 2010 21:47:50 +0000, Sean Kelly wrote:
>> 
>> > -profile currently doesn't work with multithreaded apps.
>> 
>> Darn. Are there plans to sort that out?
> 
> It's been on my "to do" list for ages.  Timing data is less/differently useful for multithreaded code, but it should at least not crash, unlike now.

I find profiling very useful in multi-threaded programs for assisting with optimisation, and am keen for it to be possible.

I use C++ in my day job (with gcc), and recently went through a lot of pain trying to get gprof to work, only to discover that it fundamentally doesn't work on multi-threaded code. I guess that is fair enough given that instrumented code can't use something as simple as a high-resolution clock to measure how long things take.

What I ended up using was sysprof, which is an external program that does statistical sampling of the whole system. It works really well, and produces a respectable call graph that shows very clearly where the time is being spent. However, when I try it with a D2 program, I don't get a call graph - presumably because it doesn't understand the stack frames and so can't work out the call graph. This renders it almost useless for D programs.