Felipe Leme's Blog: Linux Archives

Posted by felipeal on June 26, 2008 at 07:23 PM | Permalink | Comments (3)

After struggling for weeks and almost giving up, I finally managed to have the Eclipse TPTP profiler working on my Ubuntu 64bits box!

As this was a painful and unbelievably hard experience (because of Eclipse TPTP, not Ubuntu/Linux, BTW), I'm going to share a few tips here.

First of all, this is going to be a quick and dirty blog. I don't have the time, patience, or motivation to do a detailed step-by-step tutorial - there are plenty available (Got google?). The problem is, you follow them and something just is not there or does not work, then you got stuck - the idea here is to provide clues on why you got stuck and how to get going.

So, let's assume you installed TPTP and try to profile a web application (which is already configured and can be ran as 'Run As -> Run on Server'). You right-click in the project, do a 'Profile As -> Profile on Server') and then... nothing. No exception, no error, no frogs failing from sky, nothing. Actually, there is one symptom: the monitor dialog opens, but empty.

I knew from previous (and frustrated) attempts that the profiler needs to run an agent (which is OS-specific) and if the agent is not running, it pops up an error message (stating that the agent is not running - when I first got that message a few weeks ago, I google for it and figure that out). As the message didn't pop up this time, I figured some exception has been just ignored by Eclipse's UI, so I decide to do a tail -f on the .log file (located on WORKSPACE_DIR/.metadata), and bingo: got a message saying that the script could not be executed. (PS: I don't have the log messages anymore, so I won't be able to copy and paste the exact message).

I will ignore for now the fact that when you download a linux tarball the proper files necessary to run the application should have all necessary executable bits turned on and jump to the point where I had to cd to ECLIPSE_INSTALL/plugins/org.eclipse.tptp.platform.ac.linux_em64t_4.4.1.v200804021410/agent_controller/bin and do a 'chmod +x *'. Once I did it, I tried to run again and got:


[: 46: ==: unexpected operator

Looking at those lines, I found some marvels of modern shell spripting:


if [ x$TEMP == x ]; then
	export TEMP=/tmp
fi

As a lazy bum with a 10GB /tmp partition, I just commented it to:


#if [ x$TEMP == x ]; then
	export TEMP=/tmp
#fi

Running it again, I got a new error now, something like (again, I don't have the output anymore):


ACServer: error while loading shared libraries: ../lib/libtptpUtils.so: short file

Sounded weird, so I decided to take a look on that file:


# file ../lib/libtptpUtils.so
ASCII Text

Very nice: not only the files on bin are not executable, but the libraries that should be a symbolic link are text files which the name of the real libraries! Never saw such think, whoever did that deserves a Duke Award! Specially because I could fix it with a quick shell command:


for i in `file *|grep  -i ascii|cut -f 1 -d : `; do new=`cat $i`; rm $i ;ln -s $new $i; done

Now that I fixed the broken files provided in the tarball, I got an 'easy' problem:


# ./ACStart.sh 
ACServer: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

After I couple of minutes googleing and apt-cache searching:



# sudo apt-get install libstdc++5

And now:


# ./ACStart.sh 
Starting Agent Controller.
ACServer started successfully.

# ./ACStop.sh 
Shutting down the Agent Controller...
ACServer stopped.

In other words, at this point I knew the non-java (the agent) part of the profiler will work, so I could try it again in the UI (notice that the only Ubuntu-specific issue here was the missing libstdc++5; all the rest was bad packaging by the PTPT project).

Back to Eclipse, I did the "Profile As" again, and... nothing. I mean, know I saw same status bar messages saying the profiler received events and such, and a 'ps -aef|grep AC' shows the agent running. But I couldn't figure out how to get the results in real time (I could export a report in HTML, which is not useful for the kind of profiling I was going to do). After googleing around, it looked like I should be able to right click the profiler elements in the Monitor view and select a 'Opening With -> Execution Statistics' editor (see? I'm even using the correct Eclipse terms at this point :-). But looks like the bastard is not available, even though when I installed the TPTP/Web project I select the option to install all the dependencies.

At this point, I thought that the only plausible issue was some missing plugin to visualize the results. I triggered the Eclipse update panel again and expanded all TPTP options to see if I found something with a reasonable name that could solve the issue... and nothing. So, as a last and desperate resource, I decided to install all remaining TPTP plugins (including some BIRT stuff), and... voilà, it worked!

Seriously, I finally got the execution statistics, method statistics, etc. I was so thrilled that I almost cried! But instead, I decided to write this quick block.

And for those non-believers (I was such one), here is a screenshot:

PS: regarding the meaning of PQP, I will leave the explanation to the Brazilian readers :-)

Firefox, profiles, and Linux

Posted by felipeal on February 27, 2007 at 08:18 PM | Permalink | Comments (4)

Have you ever spent hours trying to run 2 instances of Firefox on Linux, using command-line arguments (like -ProfileManager) that *used* to work, but now simply open a window in the same Firefox process? If you did, this blog is for you...

First of all, Mozilla-based products like Firefox use profiles. That feature is so useful that it deserves a blog of its own (no, I won´t reinvent the wheel). But basically speaking, it means you can create different profiles, each with its own mozilla data (like cookies, bookmarks, passwords, etc...), and use them simultaneously. This is quite useful when you are developing web applications and must test it as different users. Or in a more mundane (and less development-based) situation, when you need to access a website using 2 different accounts (for instance, I have 2 main GMail accounts, felipeal and felipealists, the former being my main user, and the latter used only for managing mailing lists).

So far, so good - no big news in the scenario I described above. The problem is, the CLI (command-line interface) seems to be broken in more recent versions of Firefox and/or Fedora Core. I.E., if I have a running firefox instance using the default profile, and type the following command in the shell:


firefox -P sidekickProfile

or even:


firefox -ProfileManager

it opens a new window using the same firefox process (and hence using the same profile), instead of starting a new process (with a different profile, or popping up the profile manager window, respectively)!

That issue has been hunting me for many months, but as I just needed that feature a couple of times during this period (and being a professional procrastinator :-), I never had the patience to figure it out what was wrong - I just su-ed to a new user and ran a different instance of firefox (which is an ugly hack).

Well, last week, I finally got ashamed of myself, decided to fight the laziness, and figured out what the problem was! Looks like somewhere in the Firefox/Mozilla evolution (I guess it was Firefox 1.5), the startup scripts assumed the responsibility of deciding if a new process should be started, or if the CLI parameters should be passed to an existing (remote) instance.

Long-story short, in order to achieve the desired (for me, at least) behavior, you must set the variable MOZ_NO_REMOTE, to any value (or even none, as seem in the second example below - don't ask me why, I've never seem such behavior before!). For instance:

MOZ_NO_REMOTE=hell,yes firefox -P sidekickProfile
MOZ_NO_REMOTE= firefox -ProfileManager

Or, in a nice Unix way, create aliases to do the job:

alias ff2=`MOZ_NO_REMOTE= firefox -P sidekickProfile`
alias pm=`MOZ_NO_REMOTE= firefox -ProfileManager`

As a final note, I will leave here my 2-cents rant: why have this behavior changed in recent versions of Firefox? I mean, I´m fine with the script taking the responsibility of reusing existing process (I guess that burden was taken care off by the Linux/Unix integration before), but once you *explicitly* pass CLI arguments to invoke the profile manager, why the hell should the script pass them to a running process???

Powered by
Movable Type 3.01D

java.net RSS Feeds