I'm having a crash I've been unable to figure out. I have a small pretty print function that so far has handled most of my needs. However while debugging I threw something at it that caused a crash, so I know it must have an issue.
The portion calling out to pp is
---
    double getRate(double taxableGrossIncome) const {
        auto sortedRange = assumeSorted(_table[]);
        auto needle = KeyValuePair(taxableGrossIncome, 0);
        auto found = sortedRange.lowerBound(needle);
        if(!found.empty) {
            writeln(pp(found)); // fine
            writeln(pp(found), taxableGrossIncome); // fine
            writeln(taxableGrossIncome, pp(found)); // crash
            return found[$-1][1];
        }
        return 0;
    }
---
I can call writeln(pp(found)) or writeln(pp(found), taxableGrossIncome), but if I try writeln(taxableGrossIncome, pp(found)) I get a  seg fault in snprintf inside of format.formatValue. It is strange to me that it is the order of args that causes the crash.

- I don't use new/delete anywhere. I do have one branch of code which checks against a pointer to print and derefences it if not null.
- In gdb before the snfrpintf call, the value to be printed is available, so my guess is somehow the local buff variable on the stack is corrupt?
- I ran through valgrind when I commented out the offending line and did not see anything unreasonable.
- pp creates an appender and passes it through to pprint with what to print and that is where formatting occurs. Maybe my creating a appender on the stack, appending to it, and then returning the contents with '.data' is not allowed/safe and for all my other uses I'm lucky?
- Between the 7th frame and 8th is where something goes wrong. The weird thing is that gdb lists the print function as having a this paramenter in addition to the two I specified. Not sure how that is happening?

So, I'm looking for advice on anything obviously wrong, any tricks of the trade that might help me track it down, what standard rules am I violating, etc.
The single file with main causing the crash is at: http://pastebin.com/M67PamQM
Also the call stack is below. Any suggestions appreciated.

Thanks
Dan

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff764990a in snprintf () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) where
#0  0x00007ffff764990a in snprintf () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000433533 in std.format.__T11formatValueTS3std5array17__T8AppenderTAyaZ8AppenderTxdTaZ.formatValue() (f=<error reading variable>, obj=50000, w=...) at /usr/include/dmd/phobos/std/format.d:1478
#2  0x0000000000433132 in std.conv.__T5toStrTAyaTxdZ.toStr() (src=50000) at /usr/include/dmd/phobos/std/conv.d:99
#3  0x00000000004330e8 in std.conv.__T6toImplTAyaTxdZ.toImpl() (value=50000) at /usr/include/dmd/phobos/std/conv.d:824
#4  0x00000000004330cc in std.conv.__T2toTAyaZ.__T2toTxdZ.to() (_param_0=50000) at /usr/include/dmd/phobos/std/conv.d:268
#5  0x000000000043305c in std.conv.__T8textImplTAyaTxdTAyaZ.textImpl() (_param_1=..., _param_0=50000) at /usr/include/dmd/phobos/std/conv.d:3060
#6  0x000000000043301b in std.conv.__T4textTxdTAyaZ.text() (_param_1=..., _param_0=50000) at /usr/include/dmd/phobos/std/conv.d:3042
#7  0x0000000000432fe1 in e.__T5printTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeTS3std5array17__T8AppenderTAyaZ8AppenderVAyaa1_20VAyaa0_VAyaa1_0aZ.print() (this=0x0, t=0x7fffffffd8b0, appender=...) at /tmp/e.d:69
#8  0x0000000000432ecd in e.__T5printTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeTS3std5array17__T8AppenderTAyaZ8AppenderVAyaa1_20VAyaa0_VAyaa1_0aZ.print() (this=0x0, t=0x7fffffffd8b0, appender=...) at /tmp/e.d:31
#9  0x000000000042d93e in e.__T5printTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeTS3std5array17__T8AppenderTAyaZ8AppenderVAyaa1_20VAyaa0_VAyaa1_0aZ.print() (t=0x7fffffffd970, appender=...) at /tmp/e.d:31
#10 0x000000000042d39d in e.__T2ppTS3std5range73__T11SortedRangeTAxS3std8typecons14__T5TupleTdTdZ5TupleVAyaa5_61203c2062Z11SortedRangeVAyaa1_20Z.pp() (item=0x7fffffffd970) at /tmp/e.d:93
#11 0x000000000042c482 in e.TaxTable.getRate() (this=0x7fffffffd9e0, taxableGrossIncome=50001) at /tmp/e.d:116
#12 0x000000000042c88e in D main () at /tmp/e.d:131
#13 0x000000000043a1f4 in rt.dmain2.main() ()
#14 0x00007fffffffdbe0 in ?? ()
#15 0x00007fffffffdac0 in ?? ()
#16 0x0000000000439b6e in rt.dmain2.main() ()
#17 0x0000000000000001 in ?? ()
#18 0x0000000000000016 in ?? ()
#19 0x000000000066a020 in ?? ()
#20 0x00007fffffffdbe0 in ?? ()
#21 0x00000000ffffffff in ?? ()
#22 0x0000000000000000 in ?? ()
(gdb)

On 10/28/2012 11:38 AM, Dan wrote:
> I'm having a crash I've been unable to figure out. I have a small pretty
> print function that so far has handled most of my needs. However while
> debugging I threw something at it that caused a crash, so I know it must
> have an issue.
> The portion calling out to pp is
> ---
> double getRate(double taxableGrossIncome) const {
> auto sortedRange = assumeSorted(_table[]);
> auto needle = KeyValuePair(taxableGrossIncome, 0);
> auto found = sortedRange.lowerBound(needle);
> if(!found.empty) {
> writeln(pp(found)); // fine
> writeln(pp(found), taxableGrossIncome); // fine
> writeln(taxableGrossIncome, pp(found)); // crash
> return found[$-1][1];
> }
> return 0;
> }
> ---

[...]

> The single file with main causing the crash is at:
> http://pastebin.com/M67PamQM

First, in order to build the code with dmd 2.060, I had to make opEquals() and getRate() non-const.

I was able to reproduce the problem in my 64-bit environment.

The workaround is to compile with -m32. It worked for me.

There are some 64-bit compilation bugs. Please create a bug report if you don't think this has already been reported:

  http://d.puremagic.com/issues/

Ali

On Monday, 29 October 2012 at 05:47:21 UTC, Ali Çehreli wrote:

> First, in order to build the code with dmd 2.060, I had to make opEquals() and getRate() non-const.
>

Thanks for the answers.
I am using v2.060 as well so I assume this is not necessary, maybe just a change you made along the way while troubleshooting?

> I was able to reproduce the problem in my 64-bit environment.
>
> The workaround is to compile with -m32. It worked for me.
>

Wow - good catch. I'm interested in moving to D because it is beautiful/powerful and now there is a nice web stack (vibe.d). I have installed vibe and it requires libraries like ssl, event_pthreads, etc. I have those included in my command line. When I simply add the -m32 as suggested it can no longer find those lib files. Do I then need to track down 32 bit versions of each and use -m32 always?

I'm just starting out and honestly I don't intend to write complex code - the pprint is hopefully more complex than I'll get. Given that, assuming linux is my target is it a recommendation to use 32 bit, or are most people doing just fine 64 bit. If the latter I'd rather live with it. Honestly I'm posting more to have experts tell what I might be doing wrong, what gotchas there are, where to look and how to troubleshoot. For instance:

- does gdb on linux at this point do the name demangling? I've tried 7.4.1 and 7.5 with no luck. Also when I pass the call stack text through ddmangle it sometimes works but ususally not.

- is anyone successfully using zerobugs on 64 bit ubuntu. When I try to install I keep getting complaints about missing gtk libraries. Not asking to troubleshoot here, just to know if others are successfully using it and is it more eye friendly with respect to naming?

> There are some 64-bit compilation bugs. Please create a bug report if you don't think this has already been reported:
>

I am not ready for that yet. When I see a seg fault I assume it is my code. I think this code is too complex or too large for me to present as a bug because I have no idea if it is really a compiler problem or not. I have a crash, I rebuild with different flags and it works does not mean compiler bug - although in this case you may be correct.

Thanks
Dan

On 10/29/2012 05:04 AM, Dan wrote:

> I have
> installed vibe and it requires libraries like ssl, event_pthreads, etc.
> I have those included in my command line. When I simply add the -m32 as
> suggested it can no longer find those lib files. Do I then need to track
> down 32 bit versions of each and use -m32 always?

Apparently, how to install 32-bit versions of libraries on Linux varies depending on the distribution. Some information is found by Google searches.

> is it a recommendation to use 32 bit, or are
> most people doing just fine 64 bit.

I wonder whether this bug is related to your case:

  http://d.puremagic.com/issues/show_bug.cgi?id=5570

After all, you do pass a struct that includes non-integral types. That bug may be it.

Ali

On Monday, 29 October 2012 at 23:02:46 UTC, Ali Çehreli wrote:
>
> I wonder whether this bug is related to your case:
>
>   http://d.puremagic.com/issues/show_bug.cgi?id=5570
>
> After all, you do pass a struct that includes non-integral types. That bug may be it.
>
> Ali

Thanks for following up and all your answers in general.

That bug may be related - but unfortunately I'll have to leave it to the experts to decide - until I learn more.

As another follow up: Do you use a debugger? Maybe you use windows and it is different/better for debugging? Ironically the original purpose of pprint was for poor man debugging capabilities.

Thanks
Dan