- Select more than one table
- Script -> Create Table Script
Nothing happens. No table script is generated. However, works fine when selecting only one table.
Great program!! Keep on going!!
Confirmed in 3.1.2
Confirmed in both 3.2.1 and 3.3.0. It'd be nice to see this fixed.
I have just tried to reproduce it - and I failed. I used the current Snapshot and 3.1.2.
Here the steps, that I have done:
- Select 2 tables in the objet browser (on the same schema)
- Right click => Scripts => Create Table Script
- Then a pop up occurs for some configuration (Configuration of multiple table scripts)
- Use the default settings and press OK
- After a few seconds, the SQL Editor opens with the generated SQL script of these 2 tables.
Please, can you provide us more informations. Like DB-Vendor and the exact steps to reproduce.
Contains the log file any exceptions?
I reproduced the problem and now describe all the details.
Oracle 9i Enterprise Edition (126.96.36.199.0)
SID: S6UTF8 (CHARSET: AL32UTF8)
OS: Windows 2003 R2
v3.3.0 (downloaded squirrel-sql-3.3.0-optional.tar.gz)
The ".squirrel-sql" directory was deleted from the users home so the test would be executed with a clean profile.
OS: Ubuntu 10.10
JRE: 6.26 (from the sun-java6-jre package, version: "6.26-1maverick")
3.) JDBC driver
Official from Oracle, filename: ojdbc-188.8.131.52-jdk14.jar
What I've done:
a.) Create new driver entry by copying the default "Oracle Thin Driver".
JDBC url for new entry is: jdbc:oracle:thin:@server6:1521:s6utf8
b.) Create new alias entry using the previously created driver and user created for this test (username: "TEST")
d.) Created two tables (TAB1 and TAB2) each with 2 columns (TAB1_COL1, TAB1_COL2, TAB2_COL1, TAB2_COL2)
e.) Exited from SQuirreL, deleted the logfile, restarted SQuirreL.
f.) Logged in to the database.
g.) Navigated to the table list in the object tree.
h.) Selected both, right-click, "Scripts / Create table script"
i.) Nothing happened.
I'll upload the squirrel-sql.log file that was created during the session with the "Create table script" action. It contains an exception regarding setting timezone. The client OS had timezone set to of "Europe/Budapest".
Apparently for some reason only the submitter of a bug report can attach files, so I cannot (attach to this one). Therefore I've uploaded my SQuirreL log to this file sharing site/URL:
Logfile provided by muzso
Thanks very much. But the log-file does not contain any hint for the problem. So, I would ask you, to provide an thread dump of the java process. The aim is to see, if the background process of the script generation is still running. I had a look at the source code and there is no DB or Driver specific code, that could be responsible for this failure. It seems, that the dialog for the script generation MUST appear :-( Hopefully, the thread dump will bring some clarification.
The thread dump will not contain any personal data.
You can use Oracle's JVisualVM to do that. (/usr/lib/jvm/java-6-sun-184.108.40.206/bin/jvisualvm) JVisualVM is part of the Java JDK (sun-java6-jdk). I am not sure, if it is also contained in the JRE package. If it is installed, you should have a launcher under "Applications => System Tools")
First run SQuirreL and reproduce the problem (don't close SQuirreL). Then start JVisualVM. You must connect JVisualVM to the Java process of Squirrel. On the left side from the application window of JVisualVM you should see a line like "net.sourceforge.squirrel_sql.client.Main(pid 10222)". Double click this entry to open a connection. After this, on the right side, you will see some tabs. Click on "Threads". Then, click on the button "Thread Dump" - now, JVisualVM will create a dump. Please post the content.
You were right: the log indeed does not contain anything about this particular problem. The timezone related exception I saw got into the log before I tried to use the script generation in SQuirreL.
I've saved the threaddump you asked (two dumps actually, a few minutes apart to see whether the given thread exits after a while or not) and uploaded them here:
The relevant thread you're looking for is this:
"Thread-9" daemon prio=10 tid=0x0a436400 nid=0x21d5 in Object.wait() [0x991a2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xa2ee7c90> (a java.awt.Component$AWTTreeLock)
- locked <0xa2ee7c90> (a java.awt.Component$AWTTreeLock)
Locked ownable synchronizers:
The stacktrace of the thread brought me on an idea: maybe the code gets stuck when I click the "OK" button in the "Configuration of multi table scripts" modal window. At least it seems from the stacktrace as if the modal window is never cleaned up. I left SQuirreL alone for some time and the thread was still there after 30 minutes! I guess it'd wait forever if I left it. :-)
I tried to find this modal window, but couldn't. I mean I closed all other apps, reduced SQuirreL's window to a small rectangle so I could move it around and check whether there's a window under/behind it, but nothing.
Then I've created a new user (I mean a new Ubuntu user from scratch), logged in and recreated the test case. The same thing: SQuirreL gets stuck with the same threaddump.
I've run an "xwininfo -root -tree" to see what windows are there at all. I've uploaded the result:
Then I've repeated the test case on a Windows XP machine and all worked well, the table scripts appeared in the SQL tab.
My first guess was that this problem is related to LTSP (Linux Terminal Server Project) since I'm using an LTSP client. To test this, I've recreated the test case on a notebook running Ubuntu Oneiric (11.10) and it failed there too. So the problem is generic to at least multiple Ubuntu versions. At this point I think you should be able to reproduce the issue in any given environment running Ubuntu (and possibly other distros with the same Xorg + Gnome versions).
Thread Dumps provided by muzso
xwininfo provided by muzso
Thanks, the thread dumps contains the important information. You come to the right conclusion. As expected, the working thread never ends. And yes, he will wait forever, if you let him :-)
Now, we have the starting point for further investigations.
But, I am confused about 2 statements:
1) The Java Virtual Machine.
You wrote, that you use sun-java6-jre from Ubuntu 10.10. But your thread dump says "OpenJDK Server VM (19.0-b09 mixed mode)". So, SQuirreL runs with OpenJDK on your machine.
2) Your instructions to reproduce.
You wrote: Selected both, right-click, "Scripts / Create table script" => Nothing happened.
Nothing? Or did the modal dialog for "Configuration of multi table
scripts" appear? As you write in your later post? I assume, that the dialog appears and after clicking OK, nothing happens.
About the Ubuntu subjects. I am running Ubuntu 10.10 and on my system, it works. Now, I had seen, that you use OpenJDK. I use the Oralce JRE. So, I have tried to switch to OpenJDK and see, it doesn't work anymore.
Please, can you verify, if it works, when you run SQuirreL with Oracle's JRE. SQuirreL will help you to find out, which JRE is running. See Help => About => System => Property java.runtime.name
You're absolutely right. :-) Sorry for the accidental misleading.
We've both OpenJDK and Sun's JDK installed (it's a terminal server for developers) and as it turns out the default Java home is set for OpenJDK.
I didn't think that it mattered whether we use plain JRE or the JRE in a JDK. That's why I did not make the distinction previously.
Running SQuirreL (both 3.2.1 and 3.3.0) with Sun's JDK (v1.6.0_26-b03) fixes the problem. :-) Running with OpenJDK v1.6.0_20 (6b20-1.9.10-0ubuntu1~10.10.2) fails the test.
As for reproducing the problem: the "Configuration of multi table scripts" dialog does appear and after I press the "OK" button (leaving everything at default settings), nothing happens. Ie. it does not switch to the "SQL" tab ... and even if I do that manually, the table scripts are not there.
Thank you for your help and the workaround! At least now I know what to look for and how to fix it if the problem occurs. :-)
Sorry. I just realized a mistake: I meant Oracle's JRE ... ;-)
(it's funny that the Debian/Ubuntu packages are still called "sun-java6-*" ... :-) )
After some more debugging of this problem, I think I have found the real problem. The task is running on his own thread, and we open a modal dialog within this thread. And we don't use the Event Dispatch Thread for this (what would be the correct way). Oracles VM can handle this, OpenJDK not.
Now, we do the modal dialog on the Event Dispatch Thread. It should work with OpenJDK.
Fixed in Subversion. The change will be available in the next snapshot and/or stable release.
Log in to post a comment.