Debian 4.0 Opera not displayable?

regexes wrote:
> richard lucassen wrote:
>> On Sun, 13 Jul 2008 20:29:16 +0200
>> regexes <regexes.TakeThisOut@gmail.com> wrote:
>>
>>>> Hmmm.. I deinstalled opera (dpkg -r opera) and then reinstalled
>>>> Opera 9.50. It works fine now. Possibly a bug in the deb package
>>>> of 9.51?
>>> Well, I thought that solved my problem. It worked fine the last 10
>>> days. I just tried to running it and now the GUI doesn't appear
>>> anymore. The process is running and I've made no configuration
>>> changes since then. Actually, it worked this morning and this
>>> evening it does not. There are no entries in any of the logs...
>>> Anybody have any idea?
>>
>> I have no idea, but I've seen the same behaviour once, I run Debian
>> testing. If you run:
>>
>> ps ax | grep opera
>>
>> I remember that you can see it running, although it's not displayed. It
>> was at the time 9.51 came out, so I replaced opera and since then no
>> problem anymore (knock knock on wood)
>>
>> What do you see when you run opera from an xterm?
>>
>> R.
>>
>
> Nothing... I never see a GUI. If I start opera from the command line,
> nothing "appears" on the Eterm, Xterm, or whatever I use... (BTW, I'm
> using Enlightenment 16.7.2.)
>
> I ran an strace and it seems to "hang" doing this...
>
> <snip>
> gettimeofday({1215975149, 641270}, NULL) = 0
> gettimeofday({1215975149, 641313}, NULL) = 0
> gettimeofday({1215975149, 641357}, NULL) = 0
> ioctl(3, FIONREAD, [0]) = 0
> gettimeofday({1215975149, 641448}, NULL) = 0
> select(47, [3 44 46], [], [], {0, 90865}) = 0 (Timeout)
> gettimeofday({1215975149, 733039}, NULL) = 0
> gettimeofday({1215975149, 733090}, NULL) = 0
> <snip>
>
> In the meantime, I've installed 9.51 just to see if I have the same
> issues as last time. Yep, I still see no GUI... process runs fine
> though.
>
> regexes

Hmmm... running it as root works (just like last time). So I ran it
from the command line and the following appears:

ERROR: ld.so: object 'libjvm.so' from LD_PRELOAD cannot be preloaded:
ignored.
ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded:
ignored.

GUI works though. Although this error message does not appear when
running it as a "normal" user, could it possibly have something to do
with the problem?

regexes

David W. Hodgins wrote:
> On Sun, 13 Jul 2008 15:05:39 -0400, regexes <regexes.DeleteThis@gmail.com> wrote:
>
>> Hmmm... running it as root works (just like last time). So I ran it
>> from the command line and the following appears:
>>
>> ERROR: ld.so: object 'libjvm.so' from LD_PRELOAD cannot be preloaded:
>> ignored.
>> ERROR: ld.so: object 'libawt.so' from LD_PRELOAD cannot be preloaded:
>> ignored.
>
> Those are normal error messages, as the bash script /usr/bin/opera still
> tries to load a very old version of java, prior to actually starting opera.
>
>> GUI works though. Although this error message does not appear when
>> running it as a "normal" user, could it possibly have something to do
>> with the problem?
>
> Any chance you've put a file called opera in ~/bin ?
>
> As the regular user, try running, at the command line, "bash -x -v /usr/bin/opera".
>
> Regards, Dave Hodgins
>

Thanks for the help. No.. I haven't created any files named opera. My
default shell for all regular users (and root) it tcsh not bash. Anyway,
why not try it... output of "bash -x -v /usr/bin/opera"...

<snip>
+ for LIBASPELL_DIR in /usr/local/lib64 /usr/lib64 /opkg/lib64
/usr/local/lib /usr/lib /opkg/lib
+ '[' -f /usr/local/lib64/libaspell.so.15 ']'
+ for LIBASPELL_DIR in /usr/local/lib64 /usr/lib64 /opkg/lib64
/usr/local/lib /usr/lib /opkg/lib
+ '[' -f /usr/lib64/libaspell.so.15 ']'
+ for LIBASPELL_DIR in /usr/local/lib64 /usr/lib64 /opkg/lib64
/usr/local/lib /usr/lib /opkg/lib
+ '[' -f /opkg/lib64/libaspell.so.15 ']'
+ for LIBASPELL_DIR in /usr/local/lib64 /usr/lib64 /opkg/lib64
/usr/local/lib /usr/lib /opkg/lib
+ '[' -f /usr/local/lib/libaspell.so.15 ']'
+ for LIBASPELL_DIR in /usr/local/lib64 /usr/lib64 /opkg/lib64
/usr/local/lib /usr/lib /opkg/lib
+ '[' -f /usr/lib/libaspell.so.15 ']'
+
LD_LIBRARY_PATH=/usr/lib/opera/9.51:/home/myuser/j2re1.4.2_08/lib/i386/:/home/myuser/j2re1.4.2_08/lib/i386//native_threads:/home/myuser/j2re1.4.2_08/lib/i386//client:/home/myuser/j2re1.4.2_08/lib/i386//server:/home/myuser/j2re1.4.2_08/lib/i386//classic:/usr/lib
+ for LIBASPELL_DIR in /usr/local/lib64 /usr/lib64 /opkg/lib64
/usr/local/lib /usr/lib /opkg/lib
+ '[' -f /opkg/lib/libaspell.so.15 ']'

# Run Opera:
exec "$OPERA_BINARYDIR/opera" "$@"
+ exec /usr/lib/opera/9.51/opera


It stops here and no GUI.

regexes

David W. Hodgins wrote:
> On Sun, 13 Jul 2008 15:22:33 -0400, regexes <regexes DeleteThis @gmail.com> wrote:
>
>> exec "$OPERA_BINARYDIR/opera" "$@"
>> + exec /usr/lib/opera/9.51/opera
>> It stops here and no GUI.
>
> Ok. Definitely getting the right version. Try running
>
> opera --debugxerror
>
> Regards, Dave Hodgins
>


output...

mymachine:myuser:~> /usr/bin/opera --debugxerror
opera: X Error: BadAtom (invalid Atom parameter) 5
Major opcode: 20
Minor opcode: 0
Resource id: 0

then hangs... no GUI.

David W. Hodgins wrote:
> On Sun, 13 Jul 2008 15:58:43 -0400, regexes <regexes.TakeThisOut@gmail.com> wrote:
>
>> mymachine:myuser:~> /usr/bin/opera --debugxerror
>> opera: X Error: BadAtom (invalid Atom parameter) 5
>> Major opcode: 20
>> Minor opcode: 0
>> Resource id: 0
>
> I get the same, followed by messages about the plugins, then the gui.
>
> Have you killed all running opera processes?
>
> Regards, Dave Hodgins
>

Hmmm... I get nothing after the "Resource id: 0" line.

"ps -ef | grep opera" returns no hits... so yeah... no opera processes
are running (unless there called something else)

regexes

David W. Hodgins wrote:
> On Sun, 13 Jul 2008 16:04:50 -0400, regexes <regexes DeleteThis @gmail.com> wrote:
>
>> "ps -ef | grep opera" returns no hits... so yeah... no opera processes
>> are running (unless there called something else)
>
> Could still be some orphaned threads, that should show with "ps -eLf|grep opera"
>
> Can't hurt to try running "killall opera". It should return
> "opera:no process killed"
>
> I'm running out ideas. Only things I can think of trying, would be a reboot
> which should not make any difference, but can't hurt to try, or perhaps trying
> out the newest beta version, 9.52 build 2065 from
> http://my.opera.com/desktopteam/blog/
>
> Regards, Dave Hodgins
>

Well, thanks for the help.

No orphaned threads running. I usually run "ps -ef" anyway and "ps
-eLf" didn't show any processes either.

I ran "killall opera" too... always receive "opera:no process killed"

I tried rebooting already and it never changes anything. I guess I'll
try build 2065.

regexes

regexes wrote:
> David W. Hodgins wrote:
>> On Sun, 13 Jul 2008 16:04:50 -0400, regexes <regexes.RemoveThis@gmail.com> wrote:
>>
>>> "ps -ef | grep opera" returns no hits... so yeah... no opera processes
>>> are running (unless there called something else)
>>
>> Could still be some orphaned threads, that should show with "ps
>> -eLf|grep opera"
>>
>> Can't hurt to try running "killall opera". It should return
>> "opera:no process killed"
>>
>> I'm running out ideas. Only things I can think of trying, would be a
>> reboot
>> which should not make any difference, but can't hurt to try, or
>> perhaps trying
>> out the newest beta version, 9.52 build 2065 from
>> http://my.opera.com/desktopteam/blog/
>>
>> Regards, Dave Hodgins
>>
>
> Well, thanks for the help.
>
> No orphaned threads running. I usually run "ps -ef" anyway and "ps
> -eLf" didn't show any processes either.
>
> I ran "killall opera" too... always receive "opera:no process killed"
>
> I tried rebooting already and it never changes anything. I guess I'll
> try build 2065.
>
> regexes

No luck.. I get exactly the same behavior with 2065. I'm at a loss
now... ????

On Mon, 14 Jul 2008 01:38:03 -0400, regexes <regexes.DeleteThis@gmail.com> wrote:

> You've got me this far... any other ideas?

Well, running opera with all debugging turned on, i.e.
opera --debugdns --debugfocus --debugfont --debugfontfilter --debuggeometry --debugjava --debugkeyboard --debuglirc --debuglocale --debugmouse --debugplugin --debugatom --debugxerror --debugshape >operadebug.txt 2>&1
indicates the first thing it does before displaying the plugin messages, is sort
out the fonts.

Try deleting ~/.opera/fontcache.txt and ~/.opera/fontswitch.ini

As to why the files would become corrupt, the primary cause I've seen, is the
kernel module acting as if something has been physically written to the hd, when
in reality, it's sitting in the hd cache, and then something causes the system
to crash. I've found this to be a major problem when using reiserfs, without
a good ups system.

I strongly recommend useing hdparm to turn off hard drive write cacheing.
It will reduce performance slightly, but in my opinion, is well worth the
cost. In /etc/rc.d/rc.local (or equivalent), add a line like
hdparm -W 0 /dev/hda

Given frequent short blackouts, I lost a lot of files, till I turned off hd
write caching. Since turning it off, I've never had any problems with file
system corruption.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:
> On Sun, 13 Jul 2008 17:05:21 -0400, regexes <regexes.DeleteThis@gmail.com> wrote:
>
>> No luck.. I get exactly the same behavior with 2065. I'm at a loss
>> now... ????
>
> Perhaps there's a corrupted file in ~/.opera. Try running "opera -pd ~/testopera".
>
> Regards, Dave Hodgins
>

That appears to be the case. When running the above command, i.e. using
"~/testopera" as the configuration directory, the GUI starts. Hmmm...
the question now is what file(s) are corrupt, why, and can it (they) be
fixed (removed)?

You've got me this far... any other ideas?

regexes

On Mon, 14 Jul 2008 14:29:14 -0400, regexes <regexes.TakeThisOut@gmail.com> wrote:

> If I delete the fontswitch.ini file, I don't get any farther. If I run
> the complete debug command above, I can see in the output that it never
> gets past the fonts... for example:

The first thing that appears to be happening after the fonts, is the plugin
probing. Try renaming ~/.opera/pluginpath.ini, or moving it out of the .opera
directory.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:
> On Mon, 14 Jul 2008 01:38:03 -0400, regexes <regexes RemoveThis @gmail.com> wrote:
>
>> You've got me this far... any other ideas?
>
> Well, running opera with all debugging turned on, i.e.
> opera --debugdns --debugfocus --debugfont --debugfontfilter --debuggeometry --debugjava --debugkeyboard --debuglirc --debuglocale --debugmouse --debugplugin --debugatom --debugxerror --debugshape >operadebug.txt 2>&1
> indicates the first thing it does before displaying the plugin messages, is sort
> out the fonts.
>
> Try deleting ~/.opera/fontcache.txt and ~/.opera/fontswitch.ini
>
> As to why the files would become corrupt, the primary cause I've seen, is the
> kernel module acting as if something has been physically written to the hd, when
> in reality, it's sitting in the hd cache, and then something causes the system
> to crash. I've found this to be a major problem when using reiserfs, without
> a good ups system.
>
> I strongly recommend useing hdparm to turn off hard drive write cacheing.
> It will reduce performance slightly, but in my opinion, is well worth the
> cost. In /etc/rc.d/rc.local (or equivalent), add a line like
> hdparm -W 0 /dev/hda
>
> Given frequent short blackouts, I lost a lot of files, till I turned off hd
> write caching. Since turning it off, I've never had any problems with file
> system corruption.
>
> Regards, Dave Hodgins
>

I only have an ~/.opera/fontswitch.ini file. There is no fontcache.txt
file.

If I delete the fontswitch.ini file, I don't get any farther. If I run
the complete debug command above, I can see in the output that it never
gets past the fonts... for example:

<snip>
Check string width using font arial [monotype], for: ...
Use font arial [monotype] for: "Panels"
Use font arial [monotype] for: "Home"
Use font arial [monotype] for: "Find"
Use font arial [monotype] for: "Save"
Use font arial [monotype] for: "Open"
Use font arial [monotype] for: "100"
Use font arial [monotype] for: "%"
Use font arial [monotype] for: "Show "
Use font arial [monotype] for: "Images"
Use font arial [monotype] for: "Fit "
Use font arial [monotype] for: "to "
Use font arial [monotype] for: "Width"
<snip>

The process is running and I have to kill it. Funny.. if I hit the
"down arrow" key while the process is running, a drop-down box with the
cached URLs pops up. Can't see anything else though...

regexes

On Mon, 14 Jul 2008 16:16:56 -0400, regexes <regexes DeleteThis @gmail.com> wrote:

> Renamed it and reran opera with the debug commands from above. No
> change.. it stops at the fonts...

Given that it works with a new personal directory, the next thing I'd try
is renaming opera6.ini. If that works, use kdiff3 to compare the newly
generated one, with the old one.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

David W. Hodgins wrote:
> On Mon, 14 Jul 2008 14:29:14 -0400, regexes <regexes RemoveThis @gmail.com> wrote:
>
>> If I delete the fontswitch.ini file, I don't get any farther. If I run
>> the complete debug command above, I can see in the output that it never
>> gets past the fonts... for example:
>
> The first thing that appears to be happening after the fonts, is the plugin
> probing. Try renaming ~/.opera/pluginpath.ini, or moving it out of the .opera
> directory.
>
> Regards, Dave Hodgins
>

Renamed it and reran opera with the debug commands from above. No
change.. it stops at the fonts...

On Tue, 15 Jul 2008 11:21:15 -0400, regexes <regexes RemoveThis @gmail.com> wrote:

> and makes me click on the license verification again. Thus, a
> comparison from one opera6.ini file to the other will be completely
> different. The only thing we've seem to have proven is that the problem
> lies in the opera6.ini file. Where though... I cannot say...

Given that the problem appears to be in the fonts, or at the very beginning
of plugin detection, those are the things I'd concentrate on. I see that
in my opera6.ini, there is a Plugin Path, in addition to what's in the
pluginpath.ini file.

Check each of the directories in the old opera6.ini Plugin Path, that isn't
in the new opera6.ini Plugin Path. I'm wondering if one of them contains a
symlink pointing to a higher directory, causing a loop.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)