On Tuesday 2013-08-06 00:46, Claudio Freire wrote:

On Mon, Aug 5, 2013 at 5:24 PM, Ilya Chernykh wrote:

...

cc1plus: out of memory allocating 3355443200 bytes after a total of 757760 bytes

You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around.

Well more importantly is that it is trying to allocate 3 gigs _at once_, which likely indicates a bug. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Aug 5, 2013 at 8:14 PM, Ilya Chernykh wrote:

...

You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around. 2. Remove optimization options that take up a lot of RAM, for the compilation unit in question. Linking is a stage where this usually happens, and there's an option explicitly for that in GCC. 3. Decree 586 is no longer supported

Well, in all fairness, there's a fourth and fifth option, but I don't think those are viable in OBS: 4. Run a customized kernel with more RAM for userspace. I think 2+2 and 3+1 are the only options, which would preclude this, but maybe they're not. 5. Do a cross build, that is, build an 586 binary with an x86-64 kernel

Under 12.3 and earlier it is built well:

https://build.opensuse.org/package/show/KDE:KDE3/kdenetwork3

How can I use your proposed options in a package included in the distribution?

Well, first of all, branch it, to work on a home project. You can't take it with upstream I see. There's no upstream (ie: KDE3). So, you could try verifying this can be worked around with compiler flags, by changing the -O2 with an -O0. It won't be good for a package (-O0 being significantly slower), but it will rule out the possibility of turning off the specific optimization rather quickly, if that's not the culprit (ie: if it still breaks, you cannot work around with with compiler flags). You can also see what changed between 12.3 and factory. There's obviously something different between the two that makes it suck up more RAM in Factory. I've had the same issue, of builds taking more RAM in Factory, and I'd guess it's GCC 4.8 that's simply more RAM hungry than 4.7, though I never hit the 3G ceiling. In any case, I did hit an ICE, so I guess 4.8.1 is buggier than 4.7.x. You should dig through GCC bug reports to see if anyone else spotted this, and whether they have a workaround for it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Aug 5, 2013 at 8:49 PM, Ilya Chernykh wrote:

On Tuesday 06 August 2013 03:53:11 Claudio Freire wrote:

...

You can also see what changed between 12.3 and factory. There's obviously something different between the two that makes it suck up more RAM in Factory. I've had the same issue, of builds taking more RAM in Factory, and I'd guess it's GCC 4.8 that's simply more RAM hungry than 4.7, though I never hit the 3G ceiling.

Are there any RAM management options in OBS so to allocate more memore to a build?

Or possibly OBS admins can just allocate more memorey under 13.1 by default due to GCC 4.8 appetites?

Yes, there are, but your problem is graver than that. You cannot allocate more RAM in 586, because you've hit the kernel's limit for a user process. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2013-08-06 01:53, Claudio Freire wrote:

...

...

You can: 1. Take it up with upstream, maybe there's something in the source that pushes the limit of the compiler, and the issue could be worked around.

Under 12.3 and earlier it is built well: https://build.opensuse.org/package/show/KDE:KDE3/kdenetwork3

You can't take it with upstream I see. There's no upstream (ie: KDE3).

Upstream would be gcc. If the memory error is reproducible and reproduces on the same file every time, take the command and substitute -c by -E such that you get the preprocessor's output instead. The crash should then be repeatable by using the -c line again when fed the .i file instead. Trim the .i file for as long as the issue happens, and submit the (hopefully small) testcase to the gcc bugtracker. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org