Unexplainable out of memory (a bug?)

Hi,
I'm trying to write some VERY simple for a simple 1d experiment. Using LabView 8.2, I have done this using OOP. I have renamed one of my directories and then could not run any of my VIs. The broken arrow massage is "could not compile this vi, out of memory". The error appears in all VI contained in the renamed directory. I have tried to open the vis in a new project, copy them to a new location,reboot etc. but the error remained. The fact that the VIs all worked before, I have tons of memory, the VIs are VERY simple, and that it all started after renaming the directory suggest that perhaps it is not a simple memory problem and perhaps a bug. Does anyone have any idea how to work around this situation?

This may not help much (make sure to try this on a copy, so you don't mess it up anymore) but I've sometimes gotten lucky by opening the lvclass files and messing around with just them open. You could also try mass compiling the project directory (under tools/advanced in LV).
I strongly suggest you setup some form of version control, (I recommend tortoisesvn which is free and fairly easy to setup). I can guarantee you the time spent learning how to use it and actually using it (I'd say anytime you fix a bug or add a feature, be sure to save all first) , will pay for it self many times over. For instance before messing with the file structure I would make sure the project was commited, then when it broke I would just revert back to before I changed it, and try with a different method.
Here's an article on how to setup a svn repository
http://thinkinging.com/2007/04/12/creating-a-local-subversion-repository-with-tortoisesvn/
Message Edited by Matt W on 12-23-2007 07:49 PM

Similar Messages

LV2012 Out of Memory Bug when Clearing Compiled Object Cache

Here is some LV2012 weird behaviour when clearing the compiled cache and having a project with source code separated from the binaries.
Steps to reproduce:
1. Open a VI in a fairly large LV project
2. With the VI open, clear the compiled cache:
3. Close the VI.
4. Open the VI
5. Watch the broken arrow and the LV Out of Memory bogus.
Br,
/Roger
Solved!
Go to Solution.

Norbert_B wrote:
Roger,
i tracked down the issue to "ExecutionBenchmark1.lvclass:Load Core.vi" and "ExecutionBenchmark2.lvclass:Load Core.vi". If removing both VIs from the main, it is compilable.
Since those VIs have their blockdiagram removed, they have to include their compilation in order to be executable. I expect this to be the source of the issue.
Can you please check if using the default VI "Load Core" for both classes work as long as LV is able to recompile those while creating the object file for the main?
thanks,
Norbert
Yep, still reproducible on my 32 bit Windows 7 home machine. Attached is the fixed code.
Also, my suspicion was right. If you try to save a project in a out of memory condition, the saved project will always display an out of memory error due to a missing block diagram.
Br,
/Roger
Attachments:
Execution_Fixed.zip ‏415 KB
Missing_BD.zip ‏419 KB

Cannot re-open project after Out of Memory message

Hi,
Problem with Encore CS3.
Here is my problem: I have spent about 2 weeks working on a DVD project made of 2h movie (about 100 files and 2h of subtitles) and about 20 slideshows with a few hundred pictures and music for each slideshow. There are about 15 pages of menus and submenus. All in all it was getting longer and longer to save and open but it was okay.
I eventually tried to produce the DVD in a hard drive folder. Then, after about 14h of computation I got the message "Out of memory". I had to quit at that point. Since then I cannot open the project anymore!
When I open the project I get a window telling me how long it will take to open the project (with an incredibly wrong estimate by the way), once reached the 100%, it never gives me control back anymore. I have to kill the process with the task manager. I have tried to let it work for hours but that does not change much.
The hardware configuration is the following:
At the crash time: Windows XP pro SP2, Duo core processor, 2 GB RAM, a couple of 500GB hard drives connected in USB.
I have since added 2 more GB RAM and now have 4GB with 3.4GB detected (as we all know Windows 32 cannot handle the full 4GB). I thought the add of the memory would make a difference. It does not! Encore uses up to 1.5GB of Ram while trying to open the project (the task manager tells me).
I have tried many many times to re-open my project as I spent too much time on it to give-up easily.
I actually managed to reopen the project a couple of times in a kind of degraded mode by removing some files from the "Transcodes" directory. I then get an error message and sometimes manage to get in. I managed twice amd twice immediately saved the project under a new name (over 7GB of files).
The problem is: I have got a couple of error message while trying to re-setup the project as I left it (remember it was a degraded mode with missing files). I never managed to go to the build stage again and I cannot reopen my project consistently. I now have 3 versions of it. None is working. I am back to starting point, unable to open the project.
If anyone has a solution to recover my project, it is much more than welcome! I hate the idea to start from scratch again. If I have to do so, I am seriously thinking to switch to Vegas and DVD architect because Premiere is unable to handle my new HDV files and I start to be fed-up with all the CS3 bugs. Saying that learning these 2 tools was long enough to not wish to learn 2 new ones.
Thanks for taking time to read all my message.
Thanks in advance for your answers.

Well, here is the solution to my own problem. I give it to you in case you get the same problem one day.
The solution is as simple as impossible to find on your own: launch Bridge before launching Encore! Yes, that's it. If Bridge is running when you start Encore and open your project, it all works just fine.
In my case, the project was a bit damaged as many files where not located properly. I just hit the "Skip all" button when prompted and got into my project. Then I re-assigned each unfound file (in italic) with the original one. That was quite easy in the end.
I find it incredible that Encore will work only when Bridge is launched. In that case, I can only recommend to have plenty of RAM. In all cases it is a nasty bug.
I hope it will help someone some day.
Cheers.

Can't open vcf file. "The file may not exist ... Out of memory or system resources"

Trying to open a vcf file (vCard) from a user. After double-clicking file, get message:
Cannot open file: C:\folder\filename.vcf. The file may not exist, you may not have permission to open it, or it may be open in another program. Right-click the folder that contains
the file, and then click Properties to check your permissions for the folder. Out of memory or system resources. Close some windows or programs and try again.
I have Outlook 2010 with SP2.
Similar error, different problem. Has workaround:
http://community.office365.com/en-us/f/172/t/198029.aspx
I turn OFF cached exchange mode. I double-click the vcf file, it opens fine.
I turn ON cached exchange mode. I double-click the vcf file, I get the erorr message again.
We have hosted Exchange, so we can't turn off cached exchange mode in Outlook.
Is this a bug? Anybody know of a fix?
By the way, if I save one of my contact as a vcf file
and double-click it, it opens fine.

Hi,
I'm marking the reply as answer as there has been no update for a couple of days.
If you come back to find it doesn't work for you, please reply to us and unmark the answer.
Best Regards,
Steve Fan
Forum Support
Come back and mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback on our support, please click
here

Lightroom 5 permanently runs out of memory

Lightroom 5 on Windows 7 32 Bit and 8 Gigabytes of memory (more than the 32 Bit system can use) permanently runs out of memory when doing some more complex edits on a RAW file, especially when exporting to 16 Bit TIFF. The RAW files were created by cameras with 10 up to 16 megapixel sensors with bit depths between 12 and 14.
After exporting one or two images to 16 Bit uncompressed TIFF an error message "Not enough memory" will be displayed and only a Lightroom restart solves that - for the next one to two exports. If an image has much brush stroke edits, every additional stroke takes more and more time to see the result until the image disappears followed by the same "Not enough memory" error message.
A tab character in the XMP sidecar file is *not* the reason (ensured that), as mentioned in a post. It seems that Lightroom in general does not allocate enough memory and frees too less/late allocated.
Please fix that bug, it's not productive permanently quit and restart Lightroom when editing/exporting a few RAW files. Versions prior to Lightroom 4 did not have that bug.
P.S. Posting here, because it was not possible to post it at http://feedback.photoshop.com/photoshop_family/topics/new It's very bad design, to let a user take much time to write and then say: "Log in", but a log in with the Adobe ID and password does not work (creating accounts on Facebook etc. is not an acceptable option, Adobe ID should be enough). Also a bugtracker such as Bugzilla would be a much better tool for improving a software and finding relevant issues to avoid duplicate postings.

First of all: I personally agree with your comments regarding the feedback webpage. But that is out of our hands since this is a user-to-user forum, and there is nothing we users can do about it.
Regarding your RAM: You are running Win7 32-bit, so 4 GB of your 8 GB of RAM sit idle since the system cannot use it. And, frankly, 4 GB is very scant for running Lr, considering that the system uses 1 GB of that. So there's only 3 GB for Lr - and that only if you are not running any other programs at the same time.
Since you have a 8 GB system already, why don't you go for Win7 64-bit. Then you can also install Lr 64-bit and that - together with 8 GB of RAM - will bring a great boost in Lr performance.
Adobe recommends to run Lr in the 64-bit version. For more on their suggestion on improving Lr performance see here:
http://helpx.adobe.com/lightroom/kb/performance-hints.html?sdid=KBQWU
for more: http://forums.adobe.com/thread/1110408?tstart=0

Hash Table Infrastructure ran out of memory Issue

I am getting ORA-32690 : Hash Table Infrastructure ran out of memory error, while executing an Informatica mapping using Oracle Database ( Test Environment)
The partition creation is as shown below.
TABLESPACE MAIN_LARGE_DATA1
PARTITION BY LIST (MKTCD)
PARTITION AAM VALUES ('AAM')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION AHT VALUES ('AHT')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION GIM VALUES ('GIM')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION CNS VALUES ('CNS')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION AOBE VALUES ('AOBE')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION DBM VALUES ('DBM')
TABLESPACE MAIN_LARGE_DATA1
Could you please provide me with a solution to this problem asap?

SQL statement and execution plan? Is there a server-side trace file created for the session?
From the brief description, it sounds like bug 6471770. See Metalink for details. The workaround for this particular bug is to either disable hash group-by, by setting +"_gby_hash_aggregation_enabled"+ to FALSE (using an ALTER SESSION statement . Or by using a NO_USE_HASH_AGGREGATION hint.
Suggest you research this problem on Metalink (aka MyOracleSupport at https://support.oracle.com)

Out of memory with no swap causes disk activity

Can someone explain what exactly is being read/written from/to disk in this situation?
I have 2 GB of RAM and no swap partitions. Occasionally I'll forget how inefficient gwenview is at displaying very large images and accidentally double-click one. The entire system freezes; even alt+sysrq keystrokes are ineffective (and yes I do have them enabled).
For about 5 minutes, the system is locked up and the hard drive light is flickering. That scares me a bit, because with no swap, what could it possibly be doing for 5 straight minutes? I used to think it was synching before doing the OOM-killing, but there's no way a sync could take that long. Judging from the sound of the hard drive, it's hda (the drive / and all the other system partitions are on).
A few times after recovering from this I've run extensive data verification and never found any evidence of corruption, but I'd like to know for sure that the kernel isn't randomly deciding to use some filesystem as swap space.
In the mean time, I'm playing with disabling overcommit -- setting vm.overcommit_memory = 2 in /etc/sysctl.conf. That enforces a hard memory commit limit of swap size + overcommit_ratio * ram size (so I've read) -- and I've also read that the default overcommit_ratio is only 50%. What the bloody hell? It's almost like someone thinks swap is more important than RAM -- hell-llo, I have 2 GB of RAM so that I can get *away* from swap!
Anyway, I've set the ratio to 97% and so far things seem happy -- if I deliberately run out of memory, the process that did it always gets killed instantly and the system doesn't freeze up on OOM anymore."
Another thing -- in all my out of memory situations so far, VMWare has been running. I suppose it's possible that VMWare is the one doing the swappage; I'll have to investigate that further.
~Felix.

I think I've finally figured this out. It's a kernel bug -- I'm guessing that under normal circumstances, the "cached" column in the free command "doesn't count" towards how much memory the system thinks it's using. After all, it's just cached copies of stuff that should be elsewhere, and if you run out of memory, you can safely dump that, right? Unfortunately, /dev/shm is counted under cached rather than used memory (as I discovered in an earlier post).
So if I've got 500 MB of stuff in /dev/shm * (which is where I mount my /tmp), there's now 500MB of stuff in the "cached" column that really does count -- system reaches all RAM full, decides it needs to dump cache, and suddenly finds that the 500MB it thought it could use isn't usable. For some reason it takes about 5 minutes of hard drive thrashing (probably because it's already chucked all of the system libraries, etc. out of cached and needs to re-read them from disk every time) before something finally figures out that it really is out of memory and that that 500MB isn't letting go and invokes OOM-killer.
*: VMWare does this; it creates a 512MB file (the amount of RAM in my virtual machine) then hides it by keeping the file open and deleting it, so the inode's still there, but you can't see it and it makes the df command really perplexing... but that's another story.
I haven't had a chance to try this with a newer kernel (maybe they've fixed it now?); I'm still running 2.6.23-ARCH here. (pacman -Syu upgrades are a major production for me because I have lots of RAID arrays and things, and an nvidia graphics card, and I use gnucash which sometimes needs manual recompiling, and so on...)

Uploading large files from applet to servlet throws out of memory error

I have a java applet that needs to upload files from a client machine
to a web server using a servlet. the problem i am having is that in
the current scheme, files larger than 17-20MB throw an out of memory
error. is there any way we can get around this problem? i will post
the client and server side code for reference.
Client Side Code:
import java.io.*;
import java.net.*;
// this class is a client that enables transfer of files from client
// to server. This client connects to a servlet running on the server
// and transmits the file.
public class fileTransferClient
private static final String FILENAME_HEADER = "fileName";
private static final String FILELASTMOD_HEADER = "fileLastMod";
// this method transfers the prescribed file to the server.
// if the destination directory is "", it transfers the file to
"d:\\".
//11-21-02 Changes : This method now has a new parameter that
references the item
//that is being transferred in the import list.
public static String transferFile(String srcFileName, String
destFileName,
String destDir, int itemID)
if (destDir.equals(""))
destDir = "E:\\FTP\\incoming\\";
// get the fully qualified filename and the mere filename.
String fqfn = srcFileName;
String fname =
fqfn.substring(fqfn.lastIndexOf(File.separator)+1);
try
//importTable importer = jbInit.getImportTable();
// create the file to be uploaded and a connection to
servlet.
File fileToUpload = new File(fqfn);
long fileSize = fileToUpload.length();
// get last mod of this file.
// The last mod is sent to the servlet as a header.
long lastMod = fileToUpload.lastModified();
String strLastMod = String.valueOf(lastMod);
URL serverURL = new URL(webadminApplet.strServletURL);
URLConnection serverCon = serverURL.openConnection();
// a bunch of connection setup related things.
serverCon.setDoInput(true);
serverCon.setDoOutput(true);
// Don't use a cached version of URL connection.
serverCon.setUseCaches (false);
serverCon.setDefaultUseCaches (false);
// set headers and their values.
serverCon.setRequestProperty("Content-Type",
"application/octet-stream");
serverCon.setRequestProperty("Content-Length",
Long.toString(fileToUpload.length()));
serverCon.setRequestProperty(FILENAME_HEADER, destDir +
destFileName);
serverCon.setRequestProperty(FILELASTMOD_HEADER, strLastMod);
if (webadminApplet.DEBUG) System.out.println("Connection with
FTP server established");
// create file stream and write stream to write file data.
FileInputStream fis = new FileInputStream(fileToUpload);
OutputStream os = serverCon.getOutputStream();
try
// transfer the file in 4K chunks.
byte[] buffer = new byte[4096];
long byteCnt = 0;
//long percent = 0;
int newPercent = 0;
int oldPercent = 0;
while (true)
int bytes = fis.read(buffer);
byteCnt += bytes;
//11-21-02 :
//If itemID is greater than -1 this is an import file
transfer
//otherwise this is a header graphic file transfer.
if (itemID > -1)
newPercent = (int) ((double) byteCnt/ (double)
fileSize * 100.0);
int diff = newPercent - oldPercent;
if (newPercent == 0 || diff >= 20)
oldPercent = newPercent;
jbInit.getImportTable().displayFileTransferStatus
(itemID,
newPercent);
if (bytes < 0) break;
os.write(buffer, 0, bytes);
os.flush();
if (webadminApplet.DEBUG) System.out.println("No of bytes
sent: " + byteCnt);
finally
// close related streams.
os.close();
fis.close();
if (webadminApplet.DEBUG) System.out.println("File
Transmission complete");
// find out what the servlet has got to say in response.
BufferedReader reader = new BufferedReader(
new
InputStreamReader(serverCon.getInputStream()));
try
String line;
while ((line = reader.readLine()) != null)
if (webadminApplet.DEBUG) System.out.println(line);
finally
// close the reader stream from servlet.
reader.close();
} // end of the big try block.
catch (Exception e)
System.out.println("Exception during file transfer:\n" + e);
e.printStackTrace();
return("FTP failed. See Java Console for Errors.");
} // end of catch block.
return("File: " + fname + " successfully transferred.");
} // end of method transferFile().
} // end of class fileTransferClient
Server side code:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
import java.net.*;
// This servlet class acts as an FTP server to enable transfer of
files
// from client side.
public class FtpServerServlet extends HttpServlet
String ftpDir = "D:\\pub\\FTP\\";
private static final String FILENAME_HEADER = "fileName";
private static final String FILELASTMOD_HEADER = "fileLastMod";
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException,
IOException
doPost(req, resp);
public void doPost(HttpServletRequest req, HttpServletResponse
resp)
throws ServletException,
IOException
// ### for now enable overwrite by default.
boolean overwrite = true;
// get the fileName for this transmission.
String fileName = req.getHeader(FILENAME_HEADER);
// also get the last mod of this file.
String strLastMod = req.getHeader(FILELASTMOD_HEADER);
String message = "Filename: " + fileName + " saved
successfully.";
int status = HttpServletResponse.SC_OK;
System.out.println("fileName from client: " + fileName);
// if filename is not specified, complain.
if (fileName == null)
message = "Filename not specified";
status = HttpServletResponse.SC_INTERNAL_SERVER_ERROR;
else
// open the file stream for the file about to be transferred.
File uploadedFile = new File(fileName);
// check if file already exists - and overwrite if necessary.
if (uploadedFile.exists())
if (overwrite)
// delete the file.
uploadedFile.delete();
// ensure the directory is writable - and a new file may be
created.
if (!uploadedFile.createNewFile())
message = "Unable to create file on server. FTP failed.";
status = HttpServletResponse.SC_INTERNAL_SERVER_ERROR;
else
// get the necessary streams for file creation.
FileOutputStream fos = new FileOutputStream(uploadedFile);
InputStream is = req.getInputStream();
try
// create a buffer. 4K!
byte[] buffer = new byte[4096];
// read from input stream and write to file stream.
int byteCnt = 0;
while (true)
int bytes = is.read(buffer);
if (bytes < 0) break;
byteCnt += bytes;
// System.out.println(buffer);
fos.write(buffer, 0, bytes);
// flush the stream.
fos.flush();
} // end of try block.
finally
is.close();
fos.close();
// set last mod date for this file.
uploadedFile.setLastModified((new
Long(strLastMod)).longValue());
} // end of finally block.
} // end - the new file may be created on server.
} // end - we have a valid filename.
// set response headers.
resp.setContentType("text/plain");
resp.setStatus(status);
if (status != HttpServletResponse.SC_OK)
getServletContext().log("ERROR: " + message);
// get output stream.
PrintWriter out = resp.getWriter();
out.println(message);
} // end of doPost().
} // end of class FtpServerServlet

OK - the problem you describe is definitely what's giving you grief.
The workaround is to use a socket connection and send your own request headers, with the content length filled in. You may have to multi-part mime encode the stream on its way out as well (I'm not about that...).
You can use the following:
http://porsche.cis.udel.edu:8080/cis479/lectures/slides-04/slide-02.html
on your server to get a feel for the format that the request headers need to take.
- Kevin
I get the out of Memory Error on the client side. I
was told that this might be a bug in the URLConnection
class implementation that basically it wont know the
content length until all the data has been written to
the output stream, so it uses an in memory buffer to
store the data which basically causes memory issues..
do you think there might be a workaround of any kind..
or maybe a way that the buffer might be flushed after
a certain size of file has been uploaded.. ?? do you
have any ideas?

Error when compiling firefox...Out of memory: Kill process 6763

I'm trying to compile the firefox version 15 as both 16.0.1 and I always get the same error, which I think leaves me with no ram even though I have 8 gigs, i try it with 8 gigs of swap but does exactly the same, here are all the facts about this problem, the only thing I have not tried is to change the compiler version, what do you think? this is a clear linkage error where the system breaks down after running out of physical memory...
ERROR--->-using yaourt -Sb or makepkg -s:
/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/toolkit/library/nsUnicharUtils.cpp:275:1: warning: always_inline function might not be inlinable [-Wattributes]
/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/toolkit/library/nsUnicharUtils.cpp:50:1: warning: always_inline function might not be inlinable [-Wattributes]
/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/toolkit/library/nsUnicharUtils.cpp:40:1: warning: always_inline function might not be inlinable [-Wattributes]
rm -f libxul.so
/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/_virtualenv/bin/python /tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/config/pythonpath.py -I../../config /tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/config/expandlibs_exec.py --depend .deps/libxul.so.pp --target libxul.so --uselist -- c++ -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros -Wcast-align -Wno-long-long -march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pthread -pipe -DNDEBUG -DTRIMMED -g -fprofile-generate -O3 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.i_o nsUnicharUtils.i_o nsBidiUtils.i_o nsSpecialCasingData.i_o nsUnicodeProperties.i_o nsRDFResource.i_o -lpthread -Wl,-O1,--sort-common,--as-needed,-z,relro -Wl,-rpath,/usr/lib/firefox -Wl,-z,noexecstack -fprofile-generate -Wl,-rpath-link,/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/bin -Wl,-rpath-link,/usr/lib ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libidentity.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsinspector.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libfileview.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libprofiler.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a ../../staticlib/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libdombindings_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libsnappy_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libthebes.a ../../staticlib/libgl.a ../../staticlib/libycbcr.a -L../../dist/bin -L../../dist/lib /tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/dist/lib/libjs_static.a -lffi -Wl,-rpath-link,/usr/lib -L/usr/lib -lssl3 -lsmime3 -lnss3 -lnssutil3 -lcrmf -lXrender -lfreetype -lfontconfig -lsqlite3 -ljpeg -lpng -lz -lhunspell-1.3 -L/usr/lib -levent -lpixman-1 ../../dist/lib/libgkmedias.a -lasound -lrt -L../../dist/bin -L../../dist/lib -L/usr/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../../dist/lib/libmozalloc.a -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0 -lX11 -lXext -lpangoft2-1.0 -lfreetype -lfontconfig -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lgtk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lgdk-x11-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0 -lXt -lgthread-2.0 -lfreetype -lstartup-notification-1 -lvpx -ldl -lrt -lrt
collect2: error: ld terminated with signal 9 [Matat]
make[6]: *** [libxul.so] Error 1
make[6]: Leaving directory `/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu/toolkit/library'
make[5]: *** [libs_tier_platform] Error 2
make[5]: Leaving directory `/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu'
make[4]: *** [tier_platform] Error 2
make[4]: Leaving directory `/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu'
make[3]: *** [default] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release/obj-x86_64-unknown-linux-gnu'
make[2]: *** [realbuild] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release'
make[1]: *** [profiledbuild] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-enric/abs-firefox/src/mozilla-release'
make: *** [build] Error 2
dmesg output on ld :
[ 1521.353469] ld invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0
[ 1521.353474] Pid: 6763, comm: ld Not tainted 3.6.0 #1
[ 1521.353475] Call Trace:
[ 1521.353482] [<ffffffff814cc68e>] ? dump_header.isra.11+0x5d/0x18e
[ 1521.353486] [<ffffffff812ae3dc>] ? ___ratelimit+0xac/0x120
[ 1521.353489] [<ffffffff810e2fb5>] ? oom_kill_process+0x275/0x3b0
[ 1521.353492] [<ffffffff810e2b10>] ? find_lock_task_mm+0x20/0x70
[ 1521.353494] [<ffffffff810e3455>] ? out_of_memory+0x1c5/0x290
[ 1521.353497] [<ffffffff810e742a>] ? __alloc_pages_nodemask+0x85a/0x870
[ 1521.353500] [<ffffffff811048c4>] ? handle_pte_fault+0x8c4/0xb10
[ 1521.353505] [<ffffffff81075ddf>] ? select_task_rq_fair+0x4cf/0x790
[ 1521.353509] [<ffffffff8100a21f>] ? native_sched_clock+0xf/0x70
[ 1521.353512] [<ffffffff8102b880>] ? do_page_fault+0x130/0x460
[ 1521.353515] [<ffffffff810e6301>] ? get_page_from_freelist+0x311/0x670
[ 1521.353519] [<ffffffff814d2275>] ? page_fault+0x25/0x30
[ 1521.353523] [<ffffffff810df577>] ? file_read_actor+0x67/0x1f0
[ 1521.353526] [<ffffffff810f6915>] ? shmem_file_aio_read+0x155/0x3a0
[ 1521.353530] [<ffffffff81128832>] ? do_sync_read+0x92/0xd0
[ 1521.353532] [<ffffffff811290c0>] ? vfs_read+0xa0/0x160
[ 1521.353535] [<ffffffff811291c7>] ? sys_read+0x47/0xa0
[ 1521.353537] [<ffffffff814d2275>] ? page_fault+0x25/0x30
[ 1521.353540] [<ffffffff814d27fd>] ? system_call_fastpath+0x1a/0x1f
[ 1521.353541] Mem-Info:
[ 1521.353543] DMA per-cpu:
[ 1521.353544] CPU 0: hi: 0, btch: 1 usd: 0
[ 1521.353545] CPU 1: hi: 0, btch: 1 usd: 0
[ 1521.353546] CPU 2: hi: 0, btch: 1 usd: 0
[ 1521.353547] CPU 3: hi: 0, btch: 1 usd: 0
[ 1521.353548] DMA32 per-cpu:
[ 1521.353550] CPU 0: hi: 186, btch: 31 usd: 0
[ 1521.353551] CPU 1: hi: 186, btch: 31 usd: 26
[ 1521.353552] CPU 2: hi: 186, btch: 31 usd: 59
[ 1521.353553] CPU 3: hi: 186, btch: 31 usd: 0
[ 1521.353554] Normal per-cpu:
[ 1521.353555] CPU 0: hi: 186, btch: 31 usd: 30
[ 1521.353556] CPU 1: hi: 186, btch: 31 usd: 156
[ 1521.353557] CPU 2: hi: 186, btch: 31 usd: 169
[ 1521.353558] CPU 3: hi: 186, btch: 31 usd: 0
[ 1521.353562] active_anon:1599337 inactive_anon:345122 isolated_anon:0
active_file:140 inactive_file:222 isolated_file:0
unevictable:17 dirty:0 writeback:0 unstable:0
free:11562 slab_reclaimable:14927 slab_unreclaimable:21150
mapped:6681 shmem:932329 pagetables:10868 bounce:0
[ 1521.353567] DMA free:15892kB min:20kB low:24kB high:28kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15644kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:8kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 1521.353568] lowmem_reserve[]: 0 3147 7925 7925
[ 1521.353575] DMA32 free:23592kB min:4520kB low:5648kB high:6780kB active_anon:2754024kB inactive_anon:412764kB active_file:16kB inactive_file:44kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3223060kB mlocked:0kB dirty:0kB writeback:0kB mapped:5892kB shmem:1294220kB slab_reclaimable:7144kB slab_unreclaimable:5108kB kernel_stack:216kB pagetables:8616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:715 all_unreclaimable? yes
[ 1521.353576] lowmem_reserve[]: 0 0 4778 4778
[ 1521.353582] Normal free:6764kB min:6860kB low:8572kB high:10288kB active_anon:3643324kB inactive_anon:967724kB active_file:544kB inactive_file:844kB unevictable:68kB isolated(anon):0kB isolated(file):0kB present:4892832kB mlocked:68kB dirty:0kB writeback:0kB mapped:20832kB shmem:2435096kB slab_reclaimable:52564kB slab_unreclaimable:79484kB kernel_stack:2968kB pagetables:34856kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2484 all_unreclaimable? yes
[ 1521.353583] lowmem_reserve[]: 0 0 0 0
[ 1521.353586] DMA: 1*4kB 0*8kB 1*16kB 0*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15892kB
[ 1521.353592] DMA32: 740*4kB 506*8kB 300*16kB 135*32kB 25*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 1*4096kB = 23872kB
[ 1521.353599] Normal: 637*4kB 0*8kB 0*16kB 2*32kB 1*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 6516kB
[ 1521.353605] 932908 total pagecache pages
[ 1521.353606] 0 pages in swap cache
[ 1521.353607] Swap cache stats: add 0, delete 0, find 0/0
[ 1521.353608] Free swap = 0kB
[ 1521.353609] Total swap = 0kB
[ 1521.369740] 2094576 pages RAM
[ 1521.369743] 80362 pages reserved
[ 1521.369744] 36619 pages shared
[ 1521.369745] 1993098 pages non-shared
[ 1521.369746] [ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[ 1521.369752] [ 2286] 0 2286 6258 269 16 0 -1000 systemd-udevd
[ 1521.369754] [ 2293] 0 2293 153174 83 229 0 0 systemd-journal
[ 1521.369757] [ 3585] 0 3585 4695 188 13 0 0 mount.ntfs-3g
[ 1521.369759] [ 3615] 0 3615 3547 140 12 0 0 crond
[ 1521.369761] [ 3616] 0 3616 6708 2523 18 0 0 preload
[ 1521.369763] [ 3617] 0 3617 17762 297 38 0 0 cupsd
[ 1521.369765] [ 3619] 0 3619 43562 313 52 0 0 NetworkManager
[ 1521.369767] [ 3620] 84 3620 6988 70 20 0 0 avahi-daemon
[ 1521.369769] [ 3621] 0 3621 6515 72 18 0 0 systemd-logind
[ 1521.369770] [ 3622] 81 3622 4595 285 14 0 -900 dbus-daemon
[ 1521.369772] [ 3626] 0 3626 2275 32 9 0 0 agetty
[ 1521.369774] [ 3627] 0 3627 6693 53 19 0 0 kdm
[ 1521.369776] [ 3628] 84 3628 6957 52 18 0 0 avahi-daemon
[ 1521.369778] [ 3631] 0 3631 45316 12716 91 0 0 X
[ 1521.369780] [ 4287] 0 4287 15666 128 36 0 0 kdm
[ 1521.369782] [ 5131] 102 5131 92417 912 41 0 0 polkitd
[ 1521.369784] [ 5132] 0 5132 53222 346 41 0 0 colord
[ 1521.369786] [ 5163] 0 5163 129753 991 153 0 0 colord-sane
[ 1521.369788] [11395] 0 11395 523912 258 62 0 0 console-kit-dae
[ 1521.369790] [11468] 1000 11468 3668 111 13 0 0 startkde
[ 1521.369792] [11480] 1000 11480 3970 37 13 0 0 dbus-launch
[ 1521.369794] [11481] 1000 11481 4839 401 15 0 0 dbus-daemon
[ 1521.369796] [11507] 1000 11507 4068 94 12 0 0 gpg-agent
[ 1521.369798] [11510] 1000 11510 3760 87 11 0 0 ssh-agent
[ 1521.369799] [11524] 1000 11524 1013 21 7 0 -300 start_kdeinit
[ 1521.369801] [11525] 1000 11525 85821 1591 149 0 -300 kdeinit4
[ 1521.369803] [11528] 1000 11528 188590 3072 227 0 0 kded4
[ 1521.369805] [11534] 1000 11534 108217 2084 173 0 0 kwalletd
[ 1521.369807] [11539] 1000 11539 107913 2348 173 0 0 kglobalaccel
[ 1521.369809] [11542] 0 11542 55597 601 43 0 0 upowerd
[ 1521.369811] [11555] 1000 11555 1047 18 7 0 0 kwrapper4
[ 1521.369813] [11556] 1000 11556 127307 2185 174 0 0 ksmserver
[ 1521.369814] [11568] 0 11568 49409 269 33 0 0 udisks-daemon
[ 1521.369816] [11573] 0 11573 12394 89 28 0 0 udisks-daemon
[ 1521.369818] [11577] 1000 11577 214097 12177 260 0 0 kwin
[ 1521.369820] [11590] 1000 11590 93530 1489 131 0 0 kactivitymanage
[ 1521.369822] [11621] 1000 11621 343123 3417 215 0 0 knotify4
[ 1521.369824] [11631] 1000 11631 175587 4370 239 0 0 krunner
[ 1521.369826] [11633] 1000 11633 246522 16714 342 0 0 plasma-desktop
[ 1521.369828] [11636] 1000 11636 216148 5325 253 0 0 lancelot
[ 1521.369830] [11639] 1000 11639 50634 268 35 0 0 mission-control
[ 1521.369831] [11643] 1000 11643 37597 405 39 0 0 akonadi_control
[ 1521.369833] [11645] 1000 11645 357276 722 81 0 0 akonadiserver
[ 1521.369835] [11652] 1000 11652 377776 6206 70 0 0 mysqld
[ 1521.369837] [11738] 1000 11738 76786 1061 110 0 0 akonadi_agent_l
[ 1521.369839] [11739] 1000 11739 76783 1056 111 0 0 akonadi_agent_l
[ 1521.369841] [11740] 1000 11740 75143 1033 111 0 0 akonadi_agent_l
[ 1521.369843] [11741] 1000 11741 75144 1042 110 0 0 akonadi_agent_l
[ 1521.369845] [11742] 1000 11742 75800 1048 112 0 0 akonadi_agent_l
[ 1521.369847] [11743] 1000 11743 75800 1054 107 0 0 akonadi_agent_l
[ 1521.369848] [11744] 1000 11744 76786 1064 108 0 0 akonadi_agent_l
[ 1521.369850] [11745] 1000 11745 76780 1073 111 0 0 akonadi_agent_l
[ 1521.369852] [11746] 1000 11746 84215 1305 155 0 0 akonadi_maildis
[ 1521.369854] [11747] 1000 11747 92098 1211 138 0 0 akonadi_nepomuk
[ 1521.369856] [11774] 1000 11774 59745 591 76 0 0 nepomukserver
[ 1521.369858] [11777] 1000 11777 287924 2235 149 0 0 nepomukservices
[ 1521.369860] [11795] 1000 11795 100823 10181 51 0 0 virtuoso-t
[ 1521.369861] [11801] 1000 11801 93041 786 99 0 0 pulseaudio
[ 1521.369863] [11802] 133 11802 41125 46 17 0 0 rtkit-daemon
[ 1521.369865] [11811] 1000 11811 17253 140 36 0 0 gconf-helper
[ 1521.369867] [11813] 1000 11813 11527 127 26 0 0 gconfd-2
[ 1521.369869] [11816] 1000 11816 68886 1148 123 0 0 kuiserver
[ 1521.369871] [11837] 1000 11837 58146 1047 105 0 0 nepomukservices
[ 1521.369873] [11839] 1000 11839 53655 966 98 0 0 nepomukservices
[ 1521.369875] [11840] 1000 11840 92263 1128 107 0 0 nepomukservices
[ 1521.369877] [11841] 1000 11841 109750 1232 107 0 0 nepomukservices
[ 1521.369878] [12942] 1000 12942 41975 542 78 0 0 kwrited
[ 1521.369880] [12944] 1000 12944 246808 6774 195 0 0 ktorrent
[ 1521.369882] [12954] 1000 12954 93430 1212 139 0 0 polkit-kde-auth
[ 1521.369884] [12957] 1000 12957 70673 1126 130 0 0 nepomukcontroll
[ 1521.369886] [12959] 1000 12959 92309 1654 138 0 0 kgpg
[ 1521.369888] [12966] 1000 12966 109879 2164 176 0 0 klipper
[ 1521.369890] [13009] 1000 13009 86477 1682 131 0 0 kio_http_cache_
[ 1521.369892] [17302] 1000 17302 270535 59165 488 0 0 firefox
[ 1521.369894] [17322] 1000 17322 10407 86 26 0 0 gvfsd
[ 1521.369896] [17324] 1000 17324 50365 171 31 0 0 gvfs-fuse-daemo
[ 1521.369897] [18462] 1000 18462 138761 5014 199 0 0 konsole
[ 1521.369899] [18464] 1000 18464 4227 156 13 0 0 bash
[ 1521.369901] [19535] 1000 19535 3885 324 13 0 0 yaourt
[ 1521.369903] [19680] 1000 19680 3800 253 13 0 0 makepkg
[ 1521.369905] [22861] 1000 22861 174765 6917 209 0 0 dolphin
[ 1521.369907] [24940] 1000 24940 12258 2121 27 0 0 Xvfb
[ 1521.369909] [24941] 1000 24941 2944 134 11 0 0 make
[ 1521.369911] [25116] 1000 25116 2946 137 11 0 0 make
[ 1521.369913] [25337] 1000 25337 3013 200 11 0 0 make
[ 1521.369915] [ 473] 1000 473 2977 169 12 0 0 make
[ 1521.369917] [ 3719] 1000 3719 3006 176 12 0 0 make
[ 1521.369919] [10784] 1000 10784 3006 175 13 0 0 make
[ 1521.369921] [12252] 1000 12252 115351 9567 175 0 0 kvirc
[ 1521.369922] [26014] 1000 26014 4256 168 13 0 0 bash
[ 1521.369925] [30177] 1000 30177 4255 167 14 0 0 bash
[ 1521.369926] [30976] 1000 30976 86977 3634 138 0 0 plugin-containe
[ 1521.369928] [ 915] 1000 915 87003 1648 132 0 0 kio_file
[ 1521.369930] [ 916] 1000 916 109277 2635 176 0 0 kio_thumbnail
[ 1521.369932] [ 1186] 1000 1186 4227 157 13 0 0 bash
[ 1521.369934] [ 2105] 1000 2105 86873 1689 132 0 0 klauncher
[ 1521.369936] [ 2473] 1000 2473 87003 1648 132 0 0 kio_file
[ 1521.369938] [ 3468] 1000 3468 141313 5962 206 0 0 kate
[ 1521.369940] [ 6331] 1000 6331 109512 2225 174 0 0 kate
[ 1521.369942] [ 6733] 1000 6733 2983 150 12 0 0 make
[ 1521.369943] [ 6760] 1000 6760 17243 1559 39 0 0 python
[ 1521.369945] [ 6761] 1000 6761 1882 30 9 0 0 c++
[ 1521.369947] [ 6762] 1000 6762 1816 23 9 0 0 collect2
[ 1521.369949] [ 6763] 1000 6763 812215 809141 1588 0 0 ld
[color=#FF40BF][ 1521.369951] Out of memory: Kill process 6763 (ld) score 402 or sacrifice child
[ 1521.369953] Killed process 6763 (ld) total-vm:3248860kB, anon-rss:3236396kB, file-rss:168kB[/color]
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.2 (GCC)
cat /proc/meminfo
MemTotal: 8056856 kB
MemFree: 1240336 kB
Buffers: 278356 kB
Cached: 4591784 kB
SwapCached: 0 kB
Active: 2700172 kB
Inactive: 3860720 kB
Active(anon): 2498432 kB
Inactive(anon): 2441488 kB
Active(file): 201740 kB
Inactive(file): 1419232 kB
Unevictable: 68 kB
Mlocked: 68 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 124 kB
Writeback: 0 kB
AnonPages: 1690996 kB
Mapped: 218032 kB
Shmem: 3249176 kB
Slab: 172972 kB
SReclaimable: 90332 kB
SUnreclaim: 82640 kB
KernelStack: 3264 kB
PageTables: 38384 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 4028428 kB
Committed_AS: 6713700 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 92972 kB
VmallocChunk: 34359642076 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 10240 kB
DirectMap2M: 7237632 kB
/etc/makepkg.conf
# ARCHITECTURE, COMPILE FLAGS
CARCH="x86_64"
CHOST="x86_64-unknown-linux-gnu"
CFLAGS="-march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
MAKEFLAGS="-j5"
thanks a lot
Last edited by papu (2012-10-13 17:35:38)

yes it's true it take 4gigs of 8 gigs i have, but when i was using gentoo never had this problem when i was compiling any package and then my pc was 4gigs.
df -hT
Filesystem Type Size Used Avail Use% Mounted on
rootfs rootfs 51G 7.7G 41G 17% /
dev devtmpfs 3.9G 0 3.9G 0% /dev
run tmpfs 3.9G 1.6M 3.9G 1% /run
/dev/sdb2 ext4 51G 7.7G 41G 17% /
tmpfs tmpfs 3.9G 76K 3.9G 1% /dev/shm
tmpfs tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
tmpfs tmpfs 3.9G 56K 3.9G 1% /tmp
/dev/sdc1 fuseblk 299G 237G 62G 80% /mnt/share
/dev/sdb1 ext2 183M 28M 146M 16% /boot
/dev/sdb3 ext4 18G 6.2G 11G 37% /home
i am using vanilla kernel 3.6.0
cat /etc/fstab
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
tmpfs /tmp tmpfs nodev,nosuid 0 0
# /dev/sdb2
UUID=412194cb-8953-4d02-94b4-d25d21bd7126 / ext4 rw,relatime,barrier=0 0 1
#/dev/sdb1
UUID=8bc28611-e3ee-4079-b311-33b9d4a0f36a /boot ext2 rw,relatime 0 2
#/dev/sdb3
UUID=2d6d63e0-a59f-439f-9c11-f6673055e65a /home ext4 rw,relatime,barrier=0 0 2
#/dev/sdc1
UUID=60F0F9D3F0F9AF80 /mnt/share ntfs-3g umask=0 0 0
what i have to do ?
thanks so much. friends!
Last edited by papu (2012-10-13 19:44:17)

Importing Word docs from RH for Word X5 - out of memory error

I've tried a few times to import 537 Word docs (2,974) from a
RH for Word project (RH X5 for Word, CHM output) into a new RH HTML
5 project. Each time, RH HTML "hangs" and I've seen "out of memory"
at least once at the very end. The original RH for Word project has
conditional build tags defined, but only one tag has been assigned
to one topic, so far. We've never been able to build an index in
this RH for Word project (it's mostly blank), but we've built a
search and contents without problems.
Is an error related to Word? Is it a bug that was fixed for
version 6? Is it somehow related to this fix:
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb401651&sliceId=1?
If it's a known bug that was fixed with a later version, then
it would further help me build a case for converting to RH 7, with
the end result of converting the whole thing eventually to RH HTML.
Thanks,
Jim

I don't do much import but if you are trying to import 537
documents in one go, nothing would surprise me. Have you tried one
at a time or a small batch at a time?
The bug you point to arose in 6 and was fixed so it is not
relevant.
My guess is it is down to memory and that most PCs would
baulk at 537 documents in one go.

"Stack overflow" & "out of memory"

Hello,
I have an issue with javascript code : with my own navigation, which includes additional javascript, I have either a "out of memory" error on the declaration of "var strUrl = http://..." in the CommonOpener_CreateExtObject method, or a "stack overflow" error on the onload="document.PCC.RaiseWindowEvent(event);" event handling in the <body> tag.
When I save the page as HTML and remove the onload event, no error happens anymore.
I think I could remove the onload event generation by modifying the C# code, but it would certainly disable some other feature (I think this event is managing PEI calls or something else).
Any idea on how to fix this ?
P.S : I'm on a .NET platform, I'm going to try to recompile my nav on a java platform to see if it works...

Sebastien,
- Are you using 5.0.1 or 5.0.2?
- Are you by any chance trying to extend the Isomorphic navigation (under 5.0.2, it's called "legacy")?
I would carefully review the pluggable nav you're using and double-check you're including all the necessary javascript in the JavaScriptIncludes() method to make sure you're basically adding everything properly.
The isomorphic nav was particularly hard to extend because it required you add a special DHTML element to close off the menus being inserted. If you base your work off of our new jsportalmenus nav, it's much easier to work with and more reliable: it injects javascript into a named DOM element, which in our case is just a <TD id='name'></TD>; the menu gets inserted in the table cell.
At a minimum, try debugging your javascript bug using Microsoft's script debugger (downloadable from microsoft.com). You should be able to determine precisely why there is a failure; comapre your code to the original nav you started from and carefully pick out what could be different.
The onload events and the PCC are critical to normal function of the portal. Sgutting that off isn't an option, in my mind. If you wanted to, you'd need to do some pretty major surgery on the portal, and thaqt wouldn't upgrade, either.
David Phipps
Plumtree Software

Out of memory exception in win2kServer

I have written a JAVA program to read an AutoCAD DXF file and grapgically display the contents as in AutoCAD. Whwn i try to pass a particular file ( say 15MB)
the JVM gives out of memory exception in Win2k Advance Server ( it takes about 70MB ) before throwing the error.
This machine has 256 mb , but in another machine whivh runs win2K profesional with128Mb opens the file without any error nd only consumes 35MB.
I use the same JVM in both machines( jdk1.3.0)
is this because of any bugs in resource allcation in the win2k Server

Have you added the -Xmx command line option to expand the default amount of memory that the JVM is allowed to allocate? Run 'java -X' for help

Exception "Out of memory" sometimes..

Hello!
I have a web server (a java servlet - vm version 1.4.1_01_b01) that needs about 1024M of memory (i uses the option -Xmx1024M) working with tomcat (3.3.1) over a pentium IV with linux (red hat).
When the users uses my server the memory that the servlet needs increases until 1024M. When memory is over 1024, java automatically manages it and all works right.
I have changed my server to a powerful machine (2 intel xeon processor with option siblings, so 4 virtual processors) and linux system (vm is the same and tomcat is version 4.1). But now, when memory is over 1024, a "out of memory exception" is dispatched (i uses -Xmx1024M too) so i have to reset my server everyday!
Does someone something about a posible bug about this strange thing? will it be something about using 2 processors?
Thanks in advance!! :)
Natalia

Thanks for your response, but i think that it isn't the problem. I'm currently using Tomcat and i have checked that the request to my server are right managed by Tomcat 4: There are several threads in the differents processors. I think i haven't to cluster my servers, Tomcat distributes the request right.
Am i right?
Anyway, thanks!
Any idea else about the problem?
Thanks in adavance! :)
Natalia

Thread: Out of memory error

I'm running a program that reads a file of more than 20k lines. Each line of this file is being processed by a thread. Sometimes the program is being halted with the out of memory error.
What can I do to solve this problem ? Is it better to change the logic of this program and instead of calling a new thread for each line, call few threads to be responsible of processing multiple lines ?
The current java version is 1.4.2.13. Upgrading it to the most recent version can solve the problem ?
I'm running it with the following configuration:
"-Xms1024m -Xmx2048m -XX urvivorRatio=10"
Thanks a lot,
Marcos.

Indeed this design is flawed. It is an old system that came to my hands and now I have to fix some bugs on it.
What is the difference between calling thousand of threads and having this backport of concurrent to take care of it ? I mean, isn't the jvm responsible for managing the both cases ?
Using the backport of concurrent and defining a limited size thread pool, what will happen if the number of lines in the file is greater than the size of this pool ?
Do you have an example or a link to where I can get a good example on how to use it ?
Thanks for helping!

Out of Memory,CS5

I have been working on a complex project for months now. In one 'module' I have multiple animations, and I am using large sub animations that scale. Now in one module, I cannot even publish the file - I am getting 'out of memory' messages, even though I have 8MB RAM and 64bit Velocity PC, WIn7. I am pulling my hair out!! Can I allocate more memory to Flash? If I look at the Task Manager. it does not show I am using the full memory. What else could it be, something corrupted? I have tried cutting it in half, but both individual halves still have the same issue. Other Flash files that are bigger in size will compile. ANyone gots any ideas? Thanks!

It could actually be this problem:
http://forums.adobe.com/thread/776817?tstart=0
I'm also getting this message when I try to convert a group of shapes and MovieClips to a new MovieClip (in some rare cases) although the file isn't even that big at all.
But I don't get the message when I try to export the Movie, it always happens when editing.
Maybe you get also bugs like: Randomly duplicating Movieclips, Empty Symbols when trying to rename them, and more.

Unexplainable out of memory (a bug?)

Similar Messages

Maybe you are looking for