Before filing a bug report against Crypto++, please verify its an actual Crypto++ bug. Experience has taught us that many times the problem is with an IDE or build system, like Eclipse or Maven. See Verify the Bug below.
When filing a bug report, please provide necessary information, like version of the Crypto++ library, the operating systm, the compiler, the CXXFLAGS used to build the Crypto++ library and your program, exact error messages and stack traces. See What to File below.
If you have a feature request, then please check the Category:Patch page. There may be a patch available for the functionality. For example, the patch page already includes patches for reading and writing PEM encoded keys, Base64URLEncoder and Base64URLDecoder and Gzip and filetimes, filenames and comments.
Verify the Bug
Before filing a bug report against Crypto++, please verify its an actual Crypto++ bug. Perform the following steps to verify its a Crypto++ bug:
git clone https://github.com/weidai11/cryptopp.git cryptopp-test cd cryptopp-test make cryptest.exe ./cryptest.exe v ./cryptest.exe tv all
cd cryptopp-test msbuild /t:Build /p:Configuration=Debug;Platform=Win32 cryptlib.vcxproj msbuild /t:Build /p:Configuration=Debug;Platform=Win32 cryptest.vcxproj msbuild /t:CopyCryptestToRoot cryptest.vcxproj .\cryptest.exe v .\cryptest.exe tv all
The steps above run the Crypto++ self tests. If the self tests pass, then the problem likely lies somewhere else, like an IDE or build system. In this case you should open a question on the Crypto++ User Group rather than filing a bug report.
Where to File
If you are experiencing trouble or a bug, then you should discuss them on the Crypto++ User Group and then file a bug report. Discussing them on the User Group helps ensure the issue comes to the attention of the right people. Otherwise, the issue may not make someone's radar.
In the distant past, the web site stated to send bug reports directly to Wei Dai. You should avoid emailing Wei directly because he is busy with his other duties and does not have the cycles to provide to Crypto++. Wei still advises us when we have questions, but we try to avoid using him as a resource because he is so busy.
What to file
When filing a bug report, please provide the following information.
- a minimal program with a main() function, that reproduces the problem
- the compiler and linker invocation
- the exact error message
- a stack trace with symbols
- version of Crypto++, operating system, and compiler
If you are experiencing a compiler, assembler or linker problem, then be sure to provide the input and output to the compiler, assembler and linker. This means we usually need to see the exact invocation of the compiler or linker, including CXXFLAGS as used during compile. Please don't post just the error message.
Some tools, like Cmake, hide information, like the compile or link command. Be sure to dig it out of the tool.
Exact error message
The exact error message is important. Please don't say ...it fails to compile or ...there is a compile error or there is a crash without telling us what the message is.
Please copy from the call stack window of your debugger, or use the bt full command in gdb.
If the crash is reproducible and you have the sources, consider adding -ggdb to CXXFLAGS before submitting a report. Please don't omit the source file and line that is problematic.
Please provide the output of uname -a command if using Unix or Linux. In addition, provide the output of lsb_release -a on Linux.
If you are using MinGW or CygWin (or some other tools-on-platform combination), be sure to provide the details.
Please provide the compiler maker and version.
For example, Visual C++ 6.0, 7.0, 7.1, or 8.0:
- 7.0: Visual Studio .NET
- 7.1: Visual Studio 2003
- 8.0: Visual Studio 2005
- 9.0: Visual Studio 2008
If using GCC, Clang or ICC, then the output of gcc -v. Sometimes the output of g++ -dummachine and g++ --version is needed.
If there is a platform or feature detection issue and you are using a GCC compatible compiler, then please include:
g++ -x c++ -dM -march=native -E - < /dev/null | sort | uniq
Sometimes we need to see what CPU features are available. If the problem seems related to cpu features, like mis-detecting them, then provide the output of /proc/cpuinfo for one of the cpu's. For example:
$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz stepping : 3 microcode : 0x9e cpu MHz : 900.109 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdt scp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_ts c aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse 3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_ti mer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pt s hwp hwp_notify hwp_act_window hwp_epp bugs : bogomips : 5424.00 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management: