Thread overview
std.regex horribly broken in 2.080?
May 04, 2018
WebFreak
May 04, 2018
Seb
May 04, 2018
Dmitry Olshansky
May 04, 2018
Dmitry Olshansky
May 04, 2018
I am currently working on workspace-d/serve-d but I am continously running into segfaults with std.regex ctRegex with the captures in dub and dscanner. I can't provide any other information really because my internet is dead right now. This issue is happening all the time there, yet I can't reproduce it. Can someone with internet maybe check where that issue might come from?

[Switching to Thread 0x7f3db0ba7700 (LWP 14593)]
0x000055f92a385dd3 in _D3std5regex__T10matchFirstTAyaTSQBfQBe__T11ctRegexImplVQBca7_5e5c647b352c7dVQBxA0Z7WrapperZQCzFNfQCsQCrZSQEaQDz__T8CapturesTQDtZQo (__HID720=0x7f3d00000001, re=...,
    input=...) at /usr/include/dlang/dmd/std/regex/package.d:980
980         import std.algorithm.iteration : map;
(gdb) bt
#0  0x000055f92a385dd3 in _D3std5regex__T10matchFirstTAyaTSQBfQBe__T11ctRegexImplVQBca7_5e5c647b352c7dVQBxA0Z7WrapperZQCzFNfQCsQCrZSQEaQDz__T8CapturesTQDtZQo (__HID720=0x7f3d00000001,
    re=..., input=...) at /usr/include/dlang/dmd/std/regex/package.d:980
#1  0x000055f92a37e459 in _D8analysis7numbers16NumberStyleCheck5visitMFxS3std12experimental5lexer__T14TokenStructureThVAyaa305_0a20202020737472696e6720636f6d6d656e743b0a20202020737472696e6720747261696c696e67436f6d6d656e743b0a0a20202020696e74206f70436d702873697a655f7420692920636f6e73742070757265206e6f7468726f77204073616665207b0a202020202020202069662028696e646578203c2069292072657475726e202d313b0a202020202020202069662028696e646578203e2069292072657475726e20313b0a202020202020202072657475726e20303b0a202020207d0a0a20202020696e74206f70436d702872656620636f6e737420747970656f66287468697329206f746865722920636f6e73742070757265206e6f7468726f77204073616665207b0a202020202020202072657475726e206f70436d70286f746865722e696e646578293b0a202020207d0aZQYoZv (
    this=0x7f3db3002100, t=...) at ../../.dub/packages/dscanner-0.4.2/dscanner/src/analysis/numbers.d:38
#2  0x000055f92a41278f in _D6dparse3ast17PrimaryExpression6acceptMxFCQBpQBl10ASTVisitorZv (this=0x7f3da805bde8, visitor=0x7f3db3002100)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d-mixin-2503:2506
#3  0x000055f92a40585d in _D6dparse3ast10ASTVisitor5visitMFxCQBhQBd17PrimaryExpressionZv (this=0x7f3db3002100, primaryExpression=0x7f3da805bde8)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d:279
#4  0x000055f92a416afd in _D6dparse3ast15UnaryExpression6acceptMxFCQBnQBj10ASTVisitorZv (this=0x7f3da805bcd8, visitor=0x7f3db3002100)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d-mixin-3252:3252
#5  0x000055f92a405eed in _D6dparse3ast10ASTVisitor5visitMFxCQBhQBd15UnaryExpressionZv (this=0x7f3db3002100, unaryExpression=0x7f3da805bcd8)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d:332
#6  0x000055f92a4046e3 in _D6dparse3ast10ASTVisitor5visitMFxCQBhQBd14ExpressionNodeZv (this=0x7f3db3002100, n=0x7f3da805bcd8)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d:137
#7  0x000055f92a408800 in _D6dparse3ast16AssignExpression6acceptMxFCQBoQBk10ASTVisitorZv (this=0x7f3da805bc98, visitor=0x7f3db3002100)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d-mixin-867:868
#8  0x000055f92a404b5d in _D6dparse3ast10ASTVisitor5visitMFxCQBhQBd16AssignExpressionZv (this=0x7f3db3002100, assignExpression=0x7f3da805bc98)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d:175
#9  0x000055f92a404298 in _D6dparse3ast10ASTVisitor5visitMFxCQBhQBd14ExpressionNodeZv (this=0x7f3db3002100, n=0x7f3da805bc98)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d:108
#10 0x000055f92a40d0ee in _D6dparse3ast10Expression6acceptMxFCQBiQBe10ASTVisitorZv (this=0x7f3da805b798, visitor=0x7f3db3002100)
    at ../../.dub/packages/libdparse-0.7.2-alpha.6/libdparse/src/dparse/ast.d-mixin-1575:1575
#11 0x000055f92a4050bd in _D6dparse3ast10ASTVisitor5visitMFxCQBhQBd10ExpressionZv (this=0x7f3db3002100, expression=0x7f3da805b798)

May 04, 2018
On Friday, 4 May 2018 at 11:39:18 UTC, WebFreak wrote:
> I am currently working on workspace-d/serve-d but I am continously running into segfaults with std.regex ctRegex with the captures in dub and dscanner. I can't provide any other information really because my internet is dead right now. This issue is happening all the time there, yet I can't reproduce it. Can someone with internet maybe check where that issue might come from?
>
> [...]

FWIW ctRegex might be deprecated soon: https://github.com/dlang/phobos/pull/6164

Does the normal regex work?
May 04, 2018
On Friday, 4 May 2018 at 11:39:18 UTC, WebFreak wrote:
> I am currently working on workspace-d/serve-d but I am continously running into segfaults with std.regex ctRegex with the captures in dub and dscanner. I can't provide any other information really because my internet is dead right now. This issue is happening all the time there, yet I can't reproduce it. Can someone with internet maybe check where that issue might come from?

I could take a look. Any chance to have the exact reproduction steps?

By the look of it something is wrong with Captures struct being destroyed twice or something. Could also be compiler issue.

Another thing is to disable inlining and I could at least see detailed stack trace.

>
> [...]

May 04, 2018
On Friday, 4 May 2018 at 14:33:09 UTC, Dmitry Olshansky wrote:
> On Friday, 4 May 2018 at 11:39:18 UTC, WebFreak wrote:
>> I am currently working on workspace-d/serve-d but I am continously running into segfaults with std.regex ctRegex with the captures in dub and dscanner. I can't provide any other information really because my internet is dead right now. This issue is happening all the time there, yet I can't reproduce it. Can someone with internet maybe check where that issue might come from?

I think I see the code where the trace comes from. Might take a shot at hackathon.

>
> I could take a look. Any chance to have the exact reproduction steps?
>
> By the look of it something is wrong with Captures struct being destroyed twice or something. Could also be compiler issue.
>
> Another thing is to disable inlining and I could at least see detailed stack trace.
>
>>
>> [...]