Pict run on Linux has a problem

[tangxutc]

When using files in the UTF-8 encoding format,there is a error:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

When using [nkf -e] to change the encoding format to EUC-JP,the problem also appear.
The files have japanese characters.

[jaccz]

Thanks for reporting the issue. Can you try debugging it a bit more to see what the root cause (and possibly a fix) might be?

[tangxutc]

File : pict-master\cli\mparser.cpp
Function : bool readLineFromFile( wifstream& file, wstring& line )
When using the 'wifstream' type,the japanese words of the input file cannot convert to the wide characters.

[jaccz]

Any suggestion on how to fix it? What should readLineFromFile look like to work for EUC-JP and all other encodings? Looking for expertise here, any help will be appreciated. Happy to accept a pull request with a fix, too. :)

[clebergnu]

@tangxutc do you have a file you can share? I think I can take a look at this issue and an actual reproducer would help.

[clebergnu]

@tangxutc ping.

[jaccz]

A duplicate of another active issue.

[TimHe95]

I have same error but different scenario:

./pict ./xxxx > test.txt
ok

./pict ./xxxx /o:15 > test.txt
hang(maybe because complicated constraints)

./pict ./xxxx /o:22 > test.txt
libc++abi.dylib: terminating with uncaught exception of type std::bad_alloc: std::bad_alloc
Abort trap: 6

./pict ./xxxx /o:23 > test.txt
Input Error: Order cannot be larger than number of parameters

[jaccz]

@Bj-He, yours does not seem like the same issue. The combinatorial order (/o) creates bigger and bigger outputs. WIth /o:15 you are probably not hanging but the output calculation is taking a long time. With /o:22 you may simply be running out of memory; have you checked for that?

I'm curious about the reason why you're going so high? Using combination orders that large is really defeating the purpose of "pairwise testing". Most applications of the tool go for /o:2 (the classic pairwise), some go up to /o:3. /o:5 is the very most I would ever apply in real life (and only in special circumstances). None of the case studies I ever saw found evidence that there are bugs left to be discovered beyond that point. If you find a bug after testing with /o:5, you are likely not doing a good job selecting the parameters and their values in your model or the failure mode has nothing to do with interactions of input parameters i.e. nothing you can do by increasing the combinatorial order.

[TimHe95]

I am not sure if it is because OOM, since the error message emerges immediately after I run the command. I use /o:22 for there is a scenario that I want the complete combination with strong constraints. Also I have another scenario that I need pairwise sampling.

Now I separate the 22-parameter into several small ones. Everything is ok now. I suppose that some comments of the scalability of the tool can be added, because when I was designing the sample space, I made some false assumptions.

Thank you.