New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perl build process leaves random files in system #16412
Comments
From @dur-randirCreated by @dur-randirStarting with the commit c0e3b4b, perl build process now leaves (on dorothy at ~/afl-bisect ±(c0e3b4b) ❯ ls -al /home/core dorothy at ~/afl-bisect ±(c0e3b4b) ❯ git clean -dfx && ./Configure drwxrwxrwx 2 root root 24576 Feb 11 01:22 . This pollutes users' systems. This leads to things like I do not find this behavior nor desirable nor sane. Perl Info
|
From @jkeenanOn Sat, 10 Feb 2018 22:29:20 GMT, randir wrote:
While I share your concern about failure to clean up files intended to be temporary, I'm having trouble replicating your results. At commit 199fc8c I cleaned my work directory, then called Configure and make test_prep as I ordinarily do. When those completed, I checked the following directories for un-cleaned-up files: / I didn't find any core.* files in any of those locations. Can you tell me where I should have been looking? Or explain a bit more about the circumstances in which these files might not be cleaned up? Thank you very much. |
The RT System itself - Status changed from 'new' to 'open' |
From @dur-randirOn Sat, 10 Feb 2018 17:07:56 -0800, jkeenan wrote:
So, here's a full picture. On linux systems, location for core files is controlled by a system-wide tunable in /proc/sys/kernel/core_pattern. Default value for it varies across different Linux distros. But, since it it's system-wide, it can only be set by root and software can't rely on it's specific value. Then, there's a second layer of defense - to allow programs some control, whether they want to leave core files after them, or not. There is a per-process limit, named 'core limit', which when set to 0 disables generating core files for this process altogether. It can be set, for example, in a shell by executing 'limit -c 0' to suppress core files from all subsequently run commands from this shell (or 'limit -c unlimited' to enable core generation for processes of all sizes). So, to reproduce this, you should: - save somewhere value of /proc/sys/kernel/core_pattern (to restore it later) |
From @jkeenanOn Sun, 11 Feb 2018 10:11:34 GMT, randir wrote:
Thanks for that explanation. I was previously unaware of /proc/sys/kernel/core_pattern. On Ubuntu that pipes a crash report to the 'apport' program described here: https://wiki.ubuntu.com/Apport. Of course, the point you made in your original post is still a concern. I don't know how to address it best. Thank you very much. -- |
From @tonycozOn Sun, 11 Feb 2018 02:11:34 -0800, randir wrote:
In 7ec112d I've added code to dist/Storable/stacksize to "ulimit -c 0"* before running the stack overflow tests. Please let me know if this fixes the problem for you. If it doesn't I'll disable this probing by default. Thanks, * where available |
From @dur-randirOn Sun, 11 Feb 2018 16:50:16 -0800, tonyc wrote:
Now it leaves no traces on linux. But then I've checked windows x64 and x86 builds using VS 2017. x64 passed flawlessly, but for x86 i've got this: - http://i.imgur.com/9WIXn60.png |
From @dur-randirOn Mon, 12 Feb 2018 12:27:01 -0800, randir wrote:
I've done this again from a clean checkout and now also compiles. Can it be that 'nmake clean' leaves something behind, as I've built 64-bit first and then 32-bit? |
From @xenuOn Mon, 12 Feb 2018, at 22:14, Sergey Aleynikov via RT wrote:
My experience says that (n)make clean can't be trusted. git clean -dxf is |
From @khwilliamsonOn 02/12/2018 01:27 PM, Sergey Aleynikov via RT wrote:
I was getting those errors last week on dromedary's win32 (whatever that I looked up error 5 and it was something about no access rights IIRC. I
|
From @tonycozOn Mon, Feb 12, 2018 at 12:27:01PM -0800, Sergey Aleynikov via RT wrote:
I expected the code I'm using to suppress that error worked on both 32 Tony |
From @tonycozOn Mon, 12 Feb 2018 15:13:53 -0800, tonyc wrote:
I'm not seeing failures in the build for x32 on VC 2015, I don't have VC 2017 installed: J:\dev\perl\git\perl\miniperl.exe "-I..\..\lib" -MExtUtils::Command -e c So I don't know what's going on. I tested: J:\dev\perl\git\perl\win32>git describe I ran the build with: nmake CCTYPE=MSVC140 WIN64=undef test-prep Tony |
From @dur-randirOn Mon, 12 Feb 2018 15:55:00 -0800, tonyc wrote:
My second try to build 32-bit version also succeeded, so I think it's fine. Seems like I've messed with consequent builds. |
From @tonycozOn Mon, 12 Feb 2018 16:04:20 -0800, randir wrote:
Thanks, closing. Tony |
@tonycoz - Status changed from 'open' to 'pending release' |
From @skajiIt is true that the perl build does not leave core files anymore, It would be nice if it does not emit such messages either. |
From [Unknown Contact. See original ticket]It is true that the perl build does not leave core files anymore, It would be nice if it does not emit such messages either. |
From @tonycozOn Wed, 21 Feb 2018 08:13:29 -0800, skaji@cpan.org wrote:
That should be fixed by 3d79e57. Tony |
From shoichikaji@gmail.comThanks Tony. On the other hand, I also found that "segfault" messages might be emitted Because people often monitor syslog data and alert themselves when a log
|
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release yesterday of Perl 5.28.0, this and 185 other issues have been Perl 5.28.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#132849 (status was 'resolved')
Searchable as RT132849$
The text was updated successfully, but these errors were encountered: